¿Se han reemplazado los tipos de ancho variable por tipos fijos en la C moderna?

Me encontré con un punto interesante hoy en una revisión en Code Review . @Veedrac recomendó en esta respuesta que los tipos de tamaño variable (por ejemplo, inty long) sean reemplazados por tipos de tamaño fijo como uint64_ty uint32_t. Cita de los comentarios de esa respuesta:

Los tamaños de int y long (y, por lo tanto, los valores que pueden contener) dependen de la plataforma. Por otro lado, int32_t siempre tiene 32 bits de longitud. Usar int solo significa que su código funciona de manera diferente en diferentes plataformas, que generalmente no es lo que desea.

@Supercat explica en parte aquí el razonamiento detrás del estándar que no fija los tipos comunes . C fue escrito para ser portátil en todas las arquitecturas, a diferencia del ensamblaje que generalmente se usaba para la programación de sistemas en ese momento.

Creo que la intención del diseño fue originalmente que cada tipo que no sea int sea la cosa más pequeña que pueda manejar números de varios tamaños, y que int sea el tamaño "de propósito general" más práctico que pueda manejar +/- 32767.

En cuanto a mí, siempre he usado int y no estoy realmente preocupado por las alternativas. Siempre he pensado que es el tipo más con el mejor rendimiento, final de la historia. El único lugar en el que pensé que el ancho fijo sería útil es cuando se codifican datos para almacenamiento o transferencia a través de una red. Raramente he visto tipos de ancho fijo en el código escrito por otros tampoco.

¿Estoy atrapado en los años 70 o hay realmente una razón para usar inten la era de C99 y más allá?

Existe un mito común y peligroso en el que los tipos como uint32_tsalvar a los programadores de tener que preocuparse por el tamaño de int. Si bien sería útil que el Comité de Normas definiera un medio para declarar enteros con una semántica independiente de la máquina, los tipos sin signo uint32_ttienen semántica demasiado floja para permitir que el código se escriba de manera limpia y portátil; Además, los tipos con signo int32tienen semántica que, para muchas aplicaciones, se definen de manera innecesariamente estricta y, por lo tanto, excluyen lo que de otro modo serían optimizaciones útiles.

Considere, por ejemplo:

uint32_t upow(uint32_t n, uint32_t exponent)
{
  while(exponent--)
    n*=n;
  return n;
}

int32_t spow(int32_t n, uint32_t exponent)
{
  while(exponent--)
    n*=n;
  return n;
}

En máquinas donde intno puede contener 4294967295, o puede contener 18446744065119617025, la primera función se definirá para todos los valores de ny exponent, y su comportamiento no se verá afectado por el tamaño de int; Además, el estándar no requerirá que produzca un comportamiento diferente en máquinas con cualquier tamaño deint Algunos valores de ny exponent, sin embargo, hará que invoque Comportamiento indefinido en máquinas donde 4294967295 es representable como unint 18446744065119617025 no lo es.

La segunda función generará Comportamiento indefinido para algunos valores de ny exponenten máquinas donde intno se puede mantener 4611686014132420609, pero generará un comportamiento definido para todos los valores den y exponenten todas las máquinas donde pueda (las especificaciones int32_timplican que el comportamiento de envoltura del complemento a dos en máquinas donde es más pequeño que int).

Históricamente, a pesar de que el Estándar no dijo nada acerca de lo que los compiladores deberían hacer con el intdesbordamiento upow, los compiladores habrían producido consistentemente el mismo comportamiento que si inthubiera sido lo suficientemente grande como para no desbordarse. Desafortunadamente, algunos compiladores más nuevos pueden tratar de "optimizar" los programas mediante la eliminación de comportamientos no obligatorios por el Estándar.

Para valores estrechamente relacionados con los punteros (y, por lo tanto, con la cantidad de memoria direccionable) como los tamaños de búfer, los índices de matriz y Windows ' lParam, tiene sentido tener un tipo entero con un tamaño dependiente de la arquitectura. Por lo tanto, los tipos de tamaño variable siguen siendo útiles. Esto es por eso que tenemos los typedefs size_t, ptrdiff_t, intptr_t, etc. Ellos tienen que ser typedefs porque ninguno de los incorporados en C número entero tipos tiene por qué ser triple de tamaño.

Así que la pregunta es si realmente char, short, int, long, ylong long siguen siendo útiles.

IME, todavía es común que los programas C y C ++ lo usen intpara la mayoría de las cosas. Y la mayoría de las veces (es decir, cuando sus números están en el rango ± 32 767 y no tiene requisitos de rendimiento rigurosos), esto funciona bien.

Pero, ¿qué sucede si necesita trabajar con números en el rango de 17-32 bits (como las poblaciones de las grandes ciudades)? Podría usar int, pero eso sería codificar una dependencia de la plataforma. Si desea cumplir estrictamente con el estándar, puede usarlo long, que tiene una garantía de al menos 32 bits.

El problema es que el estándar C no especifica ningún tamaño máximo para un tipo entero. Hay implementaciones en las que longes de 64 bits, lo que duplica el uso de su memoria. Y si estoslong son elementos de una matriz con millones de elementos, agotarás la memoria como un loco.

Por lo tanto, ni inttampoco longes un tipo adecuado para usar aquí si desea que su programa sea multiplataforma y eficiente en memoria. Introduzca int_least32_t.

• Su compilador I16L32 le ofrece 32 bits long, evitando los problemas de truncamiento deint
• Su compilador I32L64 le ofrece 32 bits int, evitando el desperdicio de memoria de los 64 bits long.
• Su compilador I36L72 le ofrece 36 bits int

OTOH, suponga que no necesita grandes cantidades o grandes matrices, pero necesita velocidad. Y intpuede ser lo suficientemente grande en todas las plataformas, pero no es necesariamente el tipo más rápido: los sistemas de 64 bits generalmente todavía tienen 32 bits int. Pero se puede usar int_fast16_ty obtener el tipo “más rápido”, ya sea int, longolong long .

Por lo tanto, hay casos de uso prácticos para los tipos de <stdint.h>. Los tipos enteros estándar no significan nada. Especialmente long, que puede ser de 32 o 64 bits, y puede o no ser lo suficientemente grande como para contener un puntero, dependiendo del capricho de los escritores del compilador.