reservada - uint8_t vs unsigned char
typedef struct uso (8)
¿Cuál es la ventaja de usar uint8_t sobre un unsigned char en C?
Sé que en casi todos los sistemas uint8_t es solo un typedef para unsigned char , ¿por qué usarlo?
Como dijiste, " casi todos los sistemas".
es probable que char sea uno de los menos propensos a cambiar, pero una vez que empieces a usar uint16_t y amigos, usar mejor las mezclas de uint8_t , e incluso puede ser parte de un estándar de codificación.
Documenta tu intención: estarás almacenando números pequeños, en lugar de un personaje.
También se ve mejor si está usando otras definiciones de tipo, como uint16_t o int32_t .
El punto es escribir código independiente de la implementación. unsigned char se garantiza que el unsigned char sea de 8 bits. uint8_t es.
En casi todos los sistemas he cumplido con uint8_t == unsigned char, pero esto no está garantizado por el estándar C. Si está intentando escribir un código portátil y importa exactamente el tamaño de la memoria, use uint8_t. De lo contrario, utilice caracteres sin firmar.
En mi experiencia, hay dos lugares donde queremos usar uint8_t para significar 8 bits (y uint16_t, etc.) y donde podemos tener campos más pequeños que 8 bits. Ambos lugares son donde el espacio importa y, a menudo, debemos analizar un volcado de los datos cuando se realiza la depuración y debemos poder determinar rápidamente lo que representa.
El primero está en los protocolos de RF, especialmente en sistemas de banda estrecha. En este entorno, es posible que debamos empaquetar toda la información que podamos en un solo mensaje. El segundo es en el almacenamiento flash, donde podemos tener un espacio muy limitado (como en sistemas integrados). En ambos casos, podemos usar una estructura de datos empaquetada en la que el compilador se encargará del empaquetado y desempaquetado para nosotros:
#pragma pack(1)
typedef struct {
uint8_t flag1:1;
uint8_t flag2:1;
padding1 reserved:6; /* not necessary but makes this struct more readable */
uint32_t sequence_no;
uint8_t data[8];
uint32_t crc32;
} s_mypacket __attribute__((packed));
#pragma pack()
El método que uses depende de tu compilador. También es posible que deba admitir varios compiladores diferentes con los mismos archivos de encabezado. Esto sucede en los sistemas integrados donde los dispositivos y servidores pueden ser completamente diferentes, por ejemplo, puede tener un dispositivo ARM que se comunique con un servidor x86 Linux.
Hay algunas advertencias con el uso de estructuras empaquetadas. El mayor problema es que debe evitar la anulación de la referencia de la dirección de un miembro. En sistemas con palabras alineadas mutibyte, esto puede resultar en una excepción desalineada, y un volcado de núcleo.
Algunas personas también se preocuparán por el rendimiento y argumentarán que el uso de estas estructuras compactas ralentizará su sistema. Es cierto que, detrás de escena, el compilador agrega código para acceder a los miembros de datos no alineados. Puede verlo mirando el código de ensamblaje en su IDE.
Pero como las estructuras empaquetadas son más útiles para la comunicación y el almacenamiento de datos, los datos se pueden extraer en una representación no empaquetada cuando se trabaja con ellos en la memoria. Normalmente, no es necesario que estemos trabajando con todo el paquete de datos en la memoria de todos modos.
Aquí hay una discusión relevante:
pragma pack (1) ni __attribute__ ((alineado (1))) funciona
¿Es __attribute __ ((empaquetado)) / #pragma pack de gcc inseguro?
http://solidsmoke.blogspot.ca/2010/07/woes-of-structure-packing-pragma-pack.html
Eso es realmente importante, por ejemplo, cuando escribe un analizador de red. los encabezados de paquetes están definidos por la especificación del protocolo, no por la forma en que funciona el compilador de C de una plataforma en particular.
Hay poco Desde el punto de vista de la portabilidad, char no puede ser más pequeño que 8 bits, y nada puede ser más pequeño que char , por lo tanto, si una implementación C dada tiene un tipo entero de 8 bits sin signo, será char . Alternativamente, puede que no tenga ninguno, en cuyo caso cualquier truco de typedef es discutible.
Podría utilizarse para documentar mejor su código en el sentido de que está claro que necesita bytes de 8 bits allí y nada más. Pero en la práctica, es una expectativa razonable prácticamente en cualquier lugar (existen plataformas DSP en las que no es cierto, pero las posibilidades de que su código se ejecute allí son escasas, y podría cometer un error usando una afirmación estática en la parte superior de su programa). tal plataforma).
Solo para ser pedantes, algunos sistemas pueden no tener un tipo de 8 bits. Según Wikipedia :
Se requiere una implementación para definir tipos de enteros de ancho exacto para N = 8, 16, 32 o 64 si y solo si tiene algún tipo que cumpla con los requisitos. No es necesario definirlos para ninguna otra N, incluso si admite los tipos adecuados.
Por lo uint8_t no se garantiza que uint8_t exista, aunque lo hará para todas las plataformas donde 8 bits = 1 byte. Algunas plataformas integradas pueden ser diferentes, pero eso se está volviendo muy raro. Algunos sistemas pueden definir que los tipos de caracteres sean de 16 bits, en cuyo caso probablemente no habrá ningún tipo de tipo de 8 bits.
Aparte de ese problema (menor), la respuesta de @Mark Ransom es la mejor en mi opinión. Use el que muestre más claramente para qué está usando los datos.
Además, uint8_t que quiso decir uint8_t (el typedef estándar de C99 proporcionado en el encabezado stdint.h ) en lugar de uint_8 (no es parte de ningún estándar).