que - Mejores prácticas: ¿Debo crear un typedef para el byte en C o C++?

size of variables in c++

Question

¿Prefieres ver algo como t_byte* (con typedef unsigned char t_byte ) o unsigned char* en el código?

Me estoy inclinando hacia t_byte en mis propias bibliotecas, pero nunca he trabajado en un proyecto grande donde se tomó este enfoque, y me pregunto acerca de las trampas.

Answer 1

Además de tu incómoda convención de nombres, creo que eso podría estar bien. Ten en cuenta que boost hace esto por ti, para ayudarte con la capacidad de plataforma cruzada:

#include <boost/integer.hpp>

typedef boost::uint8_t byte_t;

Tenga en cuenta que generalmente los tipos tienen el sufijo _t , como en byte_t .

Answer 2

Personalmente prefiero boost::int8_t y boost::uint8_t .

Si no desea utilizar boost, puede pedir prestado boost/cstdint.hpp .

Otra opción es usar la versión portátil de stdint.h (enlace de this respuesta).

Answer 3

Prefiero que los tipos transmitan el significado de los valores almacenados en él. Si necesito un tipo que describa un byte como está en mi máquina, prefiero byte_t en lugar de caracteres unsigned char , lo que podría significar casi cualquier cosa. (He estado trabajando en una base de código que utiliza caracteres con unsigned char o unsigned char para almacenar cadenas UTF-8). Lo mismo ocurre con uint8_t . Se podría usar así: un entero sin signo de 8 bits.

Con byte_t (como con cualquier otro tipo con nombre apropiado), rara vez es necesario buscar lo que se define (y si es así, un buen editor necesitará 3 segundos para buscarlo por usted; tal vez 10 segundos, si el código la base es enorme), y con solo mirarla queda claro qué se almacena en los objetos de ese tipo.

Answer 4

Prefiero usar tipos estándar, unsigned char, uint8_t, etc., por lo que cualquier programador que busque en la fuente no tiene que volver a consultar los encabezados para escribir el código. Cuantas más fuentes de escritura utilice, más tiempo le tomará a otros conocer sus convenciones de escritura. Para las estructuras, use absolutamente typedefs, pero para las primitivas, utilícelas con moderación.

Answer 5

Si está utilizando C99 o más reciente, debe usar stdint.h para esto. uint8_t , en este caso.

C ++ no obtuvo este encabezado hasta que C ++ 11 lo llamó cstdint . Las versiones anteriores de Visual C ++ no le permitían usar stdint.h de C99 en el código de C ++, pero casi todos los compiladores de C ++ 98 sí lo tenían, por lo que puede tener esa opción incluso cuando usa compiladores antiguos.

Al igual que con muchas otras cosas, Boost uint8_t esta diferencia en boost/integer.hpp , que proporciona cosas como uint8_t si la biblioteca de C ++ estándar de su compilador no lo hace.

Answer 6

Sugiero que si su compilador lo admite use los tipos de encabezado C99 <stdint.h> como uint8_t y int8_t .

Si su compilador no lo soporta, cree uno. Here''s un ejemplo para VC ++ , cuyas versiones anteriores no tienen stdint.h . GCC soporta stdint.h , y de hecho la mayor parte de C99

Un problema con su sugerencia es que el signo de char está definido por la implementación, por lo que si crea un alias de tipo. Al menos debes ser explícito sobre el signo. Hay algo de mérito en la idea ya que en C #, por ejemplo, un char es de 16 bits. Pero también tiene un tipo de byte.

Nota adicional...

No hubo ningún problema con su sugerencia, de hecho, sí especificó sin firmar.

También sugeriría que se utilice el char simple si los datos son datos de caracteres, es decir, es una representación de texto sin formato como el que se muestra en una consola. Esto presentará menos problemas de acuerdo de tipo al usar bibliotecas estándar y de terceros. Si, por otra parte, los datos representan una entidad sin carácter, como un mapa de bits, o si se trata de datos numéricos de "pequeño entero" sobre los cuales puede realizar una manipulación aritmética, o datos sobre los que realizará operaciones lógicas, entonces uno de los Se deben usar los tipos stdint.h (o incluso un tipo definido a partir de uno de ellos).

Hace poco me encontré con un compilador de TI C54xx donde char es en realidad de 16 bits, por lo que es posible usar stdint.h cuando sea posible, incluso si lo usas para definir un tipo de byte es preferible suponer que un unsigned char es un alias adecuado .