uint8_t - uint32_t vs int como una convención para la programación diaria
variable uint32_t (4)
¿Cuándo se deben usar los tipos de datos de stdint.h? ¿Es correcto usarlos siempre como una convención? ¿Cuál fue el propósito del diseño de tipos de tamaño no específicos como int y short?
¿Cuándo se deben usar los tipos de datos de stdint.h?
- Cuando las tareas de programación especifican el ancho del entero, especialmente para acomodar algún formato de archivo o protocolo de comunicación.
- Cuando se requiere un alto grado de portabilidad entre plataformas sobre el rendimiento .
¿Es correcto usarlos siempre como una convención (entonces)?
Las cosas se están inclinando de esa manera. Los tipos de ancho fijo son una adición más reciente a C. Original C tenía char, short, int, long
y fue progresivo, ya que intentó, sin ser demasiado específico, acomodar los diversos tamaños de enteros disponibles en una amplia variedad de procesadores y entornos . Como C tiene 40 años, habla del éxito de esa estrategia. Se ha escrito mucho código C y se hace con éxito con el tamaño de la especificación del entero suave. Con necesidades crecientes de consistencia, char, short, int, long and long long
, no son suficientes (o al menos no tan fáciles) y así int8_t, int16_t, int32_t, int64_t
. Los nuevos idiomas tienden a requerir tipos de enteros fijos muy específicos y el complemento de 2. A medida que son exitosos, la presión darwiniana presionará a C. Mi bola de cristal dice que veremos una migración lenta hacia usos crecientes de tipos de ancho fijo en C.
¿Cuál fue el propósito del diseño de tipos de tamaño no específicos como int y short?
Fue un buen primer paso para acomodar la amplia variedad de varios anchos de enteros (8,9,12,18,36, etc.) y codificaciones (2''s, 1''s, sign / mag). Tanta codificación hoy en día utiliza enteros de tamaño de potencia de 2 con el complemento de 2, de modo que uno no puede darse cuenta de que existían de antemano muchos otros acuerdos. Ver esta answer también.
Los tipos de datos de ancho fijo se deben usar solo cuando realmente se requieren (por ejemplo, cuando se implementan protocolos de transferencia o acceso a hardware o se requiere un cierto rango de valores (debe usar la variante ..._least_...
allí)). Su programa no se adaptará a otros entornos modificados (por ejemplo, el uso de uint32_t
para uint32_t
de archivo podría estar bien hace 10 años, pero off_t
se adaptará a las necesidades recientes). Como han señalado otros, podría haber un impacto en el rendimiento, ya que int
podría ser más rápido que uint32_t
en plataformas de 16 bits.
int
propio int
es muy problemático debido a su firmeza; es mejor usar, por ejemplo, size_t
cuando la variable contiene el resultado de strlen()
o sizeof()
.
Mi trabajo exige que los use y realmente me encanta usarlos.
Me resulta útil cuando tengo que implementar un protocolo y usarlos dentro de una estructura que puede ser un mensaje que se debe enviar o un titular de cierta información.
Si tengo que usar un número de secuencia que necesita ser incrementado, no usaría int porque los números de secuencia no deberían ser negativos. Yo uso uint32_t en su lugar. Por lo tanto, conoceré el espacio del número de secuencia y puedo planificar / codificar en consecuencia.
El código que escribimos se ejecutará en máquinas de 32 y 64 bits, por lo que usar "int" en diferentes máquinas de bits da como resultado errores sutiles que pueden ser difíciles de identificar. El uso de unint16_t asignará 16 bits en una arquitectura de 32 o 64 bits.
No, yo diría que nunca es una buena idea usarlos para la programación de propósito general.
Si realmente te importa la cantidad de bits, entonces adelante y úsalos, pero para la mayoría del uso general no te importa, entonces usa los tipos generales. Los tipos generales pueden ser más rápidos, y ciertamente son más fáciles de leer y escribir.