uint8_t uint32_t que c++ cstdint

c++ - uint8_t - uint32_t que es



¿Debo usar cstdint? (6)

He estado reflexionando sobre si debo usar o no los typedefs dentro de <cstdint> o no.

Personalmente, prefiero escribir uint32_t sobre unsigned int e int8_t sobre char etc ... ya que para mí es mucho más intuitivo.

¿Qué piensan ustedes? ¿Es una buena idea usar los typedefs de <cstdint> o no? ¿Hay alguna desventaja?


Básicamente, parece que no tienes ninguna pista entre uint32_t y unsigned int. Esto es perfectamente normal, ya que no necesariamente sabrá cómo se usará su tipo más adelante.

Solo usa un typedef.

Independientemente de si necesita un int sin firmar o un uint32_t (que puede pensar más adelante, cuando tenga una visión más completa de lo que será su programa), usar un typedef le ayudará a hacer su código más claro al especificar lo que realmente es manipular, y hará que sea más fácil cambiar a otro tipo cuando descubra meses después de que su elección inicial fue la peor. No hay una "respuesta correcta" aquí, porque por lo general las resuelves por el camino difícil. Es doloroso interoperar entre una biblioteca que quiere uint32_t y alguna otra biblioteca que quiera ints.


Deberías usar ambos. Debe usar int , como se explica en las otras respuestas, cuando necesite un entero de "tamaño razonable". Usa char cuando necesites un personaje: es autodocumentado.

Deberías usar uint32_t y uint32_t amigos cuando interactúas con el mundo exterior en binario: cuando realizas la programación de red, manejas archivos binarios o usas codificaciones extranjeras de varios bytes, etc. En estos casos, el tamaño exacto de un tipo es crucial para escribir correctamente, es portátil código de auto-documentación Para eso <stdint.h> (o C ++ 0x <cstdint> ).

(La endianidad es igualmente crucial, pero eso es otro asunto completamente diferente).


Depende del propósito de la variable.

Si necesita un contador de bucle, use int . Si necesita una cadena, use una matriz de caracteres.

Si necesita una variable numérica que pueda contener de -1 a 100, int8_t es bueno. Si necesita representar un valor de 0 a 100,000, entonces uint32_t uint_least32_t (gracias @Serge) es una excelente opción.


En realidad, sugeriría usar ambos.

Si desea algo definitivamente sin signo de 32 bits, use uint32_t. Por ejemplo, si está implementando una "estructura" para representar un objeto externo cuya especificación define uno de sus campos como 32 bits sin signo.

Si desea algo que sea el "tamaño de palabra natural de la máquina", use int o unsigned int. Por ejemplo:

for (int i = 0 ; i < 200 ; ++i) // stuff

El "tamaño de palabra natural de la máquina" le proporcionará el mejor rendimiento, tanto en los procesadores de hoy como en los de mañana.

Use "char" si quiere decir "personaje"; "char" o "char sin signo" si quiere decir "byte". C / C ++ le permite acceder a los bytes de un objeto arbitrario a través de "char *", nada más, estrictamente hablando.

Use uint8_t o int8_t si desea específicamente un entero de 8 bits, similar a uint32_t.


Una situación particular en la que necesitará usar los typedefs de cstdint es cuando se trata de un código que genera muchas conversiones puntero-a-int, en cuyo caso el uso de intptr_t es un requisito absoluto.

En la empresa para la que trabajo, nos estamos preparando para migrar de 32 bits a 64 bits de código C / C ++ de baja calidad que sigue arrojando punteros a int y luego a punteros, lo que definitivamente fallará en las arquitecturas de 64 bits, así que lo haremos intentar desinfectar el código siempre que sea posible (es decir, modificar estructuras de datos e interfaces para eliminar por completo la necesidad de moldes) y usar intptr_t en lugar de int en todos los demás.

En una nota al margen: el casting en general debería levantar sospechas, pero en serio, lanzar punteros a números enteros es casi siempre la consecuencia de un defecto serio en algún lugar de su diseño. Básicamente, estás mintiendo al compilador, a la plataforma y, lo que es más importante, a tus compañeros de trabajo cada vez que ocultas un puntero detrás de un int.

Aparte de eso, como otros dijeron: use tipos genéricos cuando sea posible y escriba el tamaño explícito cuando sea necesario.


Use template y programación genérica siempre que sea posible. ¡No confíe en ningún tipo si no tiene que hacerlo!

Si tiene una función que toma un número y lo devuelve multiplicado por 2, escríbalo así:

template <typename Number> inline Number doubleNum(Number n) { return 2*n; }

O incluso esto:

template <typename RetType, typename NumberType> inline RetType doubleNum(NumberType n) { return 2*n; }

De esta forma, si tiene una biblioteca que usa int s, double s, uint64_t s, lo que usted uint64_t , puede trabajar con ella, sin reescribir su código. Si necesita trabajar con archivos binarios o programación de red, puede trabajar con tipos de tamaño fijo, sin reescribir su código. Y si necesita números de precisión arbitrarios, puede trabajar con una clase que implemente la misma interfaz como un entero primitivo o tipo flotante a través de la sobrecarga del operador, como un contenedor GMP, sin reescribir su código .

Y puede especializar funciones o clases con plantillas, para optimizar casos específicos o trabajar con clases (o struct C) que no se ajusten a la interfaz relevante:

/* * optimization: * primitive integers can be bit-shifted left to * achieve multiplication by powers of 2 * (note that any decent compiler will do this * for you, behind the hood.) */ template <> inline int doubleNum<int>(int n) { return n<<1; } /* * optimization: * use assembly code */ template <> inline int32_t doubleNum<int32_t>(int32_t n) { asm { ... } } /* * work with awkward number class */ template <> inline AwkwardNumber doubleNum<AwkwardNumber>(AwkwardNumber n) { n.multiplyBy(2); return n; }