¿Por qué todo el mundo escribe sobre tipos C estándar?

Para las bibliotecas más antiguas, esto es necesario porque el encabezado en cuestión (stdint.h) no existía.

Todavía hay, sin embargo, un problema: esos tipos (uint64_t y otros) son una característica opcional en el estándar. Por lo tanto, una implementación de cumplimiento podría no incluir con ellos force y por lo tanto obligar a las bibliotecas a incluirlos todavía hoy en día.

stdint.h se ha estandarizado desde 1999. Es más probable que muchas aplicaciones definan (efectivamente alias) tipos para mantener la independencia parcial de la arquitectura de la máquina subyacente.

Proporcionan a los desarrolladores la confianza de que los tipos utilizados en su aplicación coinciden con las suposiciones específicas de su proyecto sobre el comportamiento que puede no coincidir con el estándar del lenguaje o la implementación del compilador.

La práctica se refleja en el diseño orientado a objetos Façade pattern y es muy abusado por los desarrolladores que invariablemente escriben clases de envoltura para todas las bibliotecas importadas.

Cuando los cumplidores eran mucho menos estándar y las arquitecturas de máquina podían variar desde 16 bits, 18 bits hasta 36 bits los mainframes de longitud de palabra esto era mucho más de una consideración. La práctica es mucho menos relevante ahora en un mundo que converge en sistemas embebidos ARM de 32 bits. Sigue siendo una preocupación para microcontroladores de gama baja con odd mapas de memoria.

Así que usted tiene el poder para typedef char a int.

Un "horror de codificación" mencionó que un encabezado de empresa tenía un punto en el que un programador quería un valor booleano, y un char era el tipo nativo lógico para el trabajo, y así escribió typedef bool char. Luego, más tarde, alguien encontró que un entero era la opción más lógica, y escribió typedef bool int. El resultado, años antes de Unicode, fue virtualmente typedef char int.

Bastante con visión de futuro, compatibilidad hacia adelante, creo.