c++ - software - ¿Por qué los programadores de C usan typedefs para cambiar el nombre de los tipos básicos?

tipos de programadores de software (9)

Así que estoy lejos de ser un experto en C, pero algo me ha estado molestando sobre el código que he estado leyendo durante mucho tiempo: ¿puede alguien explicarme por qué los programadores de C (++) usan typedefs para cambiar el nombre de tipos simples? Entiendo por qué los usaría para las estructuras, pero ¿cuál es exactamente la razón de las declaraciones que veo?

typedef unsigned char uch; typedef uch UBYTE; typedef unsigned long ulg; typedef unsigned int u32; typedef signed short s16;

¿Hay alguna ventaja en esto que no esté clara para mí (un programador cuya experiencia comienza con Java y no se ha aventurado mucho más allá de lenguajes estrictamente seguros de tipos)? Porque no se me ocurre ninguna razón para hacerlo, parece que solo haría que el código sea menos legible para las personas que no están familiarizadas con el proyecto.

Siéntete libre de tratarme como un novato en C, honestamente sé muy poco al respecto y es probable que haya cosas que no entendí desde el principio. ;)

A continuación hay una cita de The C Programming Language (K&R)

Además de los problemas puramente estéticos, hay dos razones principales para usar typedefs.

Primero- para parametrizar un programa

El primero es parametrizar un programa contra problemas de portabilidad. Si se usan typedefs para tipos de datos que pueden ser dependientes de la máquina, solo se deben cambiar las typedefs cuando se mueve el programa.
Una situación común es usar los nombres typedef para varias cantidades de enteros, luego hacer un conjunto apropiado de opciones de corto, int y largo para cada máquina host. Los tipos como size_t y ptrdiff_t de la biblioteca estándar son ejemplos.

Las partes en cursiva nos dicen que los programadores typedef tipo básico para la portabilidad. Si quiero asegurarme de que mi programa funciona en diferentes plataformas, usando un compilador diferente, trataré de asegurar que su portabilidad en todas las formas posibles y typedef sea una de ellas.

Cuando comencé a programar usando el compilador Turbo C en la plataforma Windows, nos dio el tamaño del int 2. Cuando me mudé a la plataforma Linux y cumplía GCC, el tamaño que obtengo es 4. Si hubiera desarrollado un programa utilizando Turbo C, en el cual confié la afirmación de que sizeof( int ) siempre es dos, no se habría adaptado correctamente a mi nueva plataforma.

Espero eso ayude.

La siguiente cita de K&R no está relacionada con su consulta, pero la he publicado también para completarla.

Segundo- proporcionar mejor documentación

El segundo propósito de typedefs es proporcionar una mejor documentación para un programa: un tipo llamado Treeptr puede ser más fácil de entender que uno declarado solo como un indicador de una estructura complicada.

A veces se usa para reducir una cosa difícil de manejar como la volatile unsigned long para algo un poco más compacta, como vuint32_t .

Otras veces es para ayudar con la portabilidad ya que los tipos como int no siempre son iguales en cada plataforma. Mediante el uso de typedef puede establecer la clase de almacenamiento que le interesa en la coincidencia más cercana de la plataforma sin cambiar todo el código fuente.

Cambiar el nombre de los tipos sin cambiar su semántica / características expuestas no tiene mucho sentido. En tu ejemplo

typedef unsigned char uch; typedef unsigned long ulg;

Pertenecen a esa categoría. No veo el punto, aparte de hacer un nombre más corto.

Pero estos

typedef uch UBYTE; typedef unsigned int u32; typedef signed short s16;

Son una historia completamente diferente. Por ejemplo, s16 significa "tipo de 16 bits con signo". Este tipo no es necesariamente signed short . El tipo específico que se ocultará detrás de s16 depende de la plataforma. Los programadores introducen este nivel adicional de direccionamiento de nombres para simplificar el soporte para múltiples plataformas. Si en alguna otra plataforma, el tipo de 16 bits signed int está signed int , el programador solo tendrá que cambiar una definición typedef. UBYTE aparentemente representa un tipo de byte de máquina sin firmar, que no es necesariamente un unsigned char .

Vale la pena señalar que la especificación C99 ya proporciona una nomenclatura estándar para los tipos integrales de ancho específico, como int16_t , uint32_t y así sucesivamente. Probablemente tenga más sentido seguir esta convención de nomenclatura estándar en plataformas que no son compatibles con C99.

Esto permite la portabilidad. Por ejemplo, necesita un tipo de entero de 32 bits sin firmar. ¿Qué tipo de estándar es ese? No lo sabes, su implementación está definida. Es por eso que escribe un tipo separado para ser un entero sin signo de 32 bits y utiliza el nuevo tipo en su código. Cuando necesite compilar en otra implementación de C, simplemente cambie el typedef s.

Hay muchas razones para ello. Lo que pienso es:

Typename se vuelve más corto y, por lo tanto, el código también es más pequeño y más legible.
Efecto de alias para nombres de estructuras más largas.
Convenio utilizado en particular equipo / empresas / estilo.
Porting: tiene el mismo nombre en todos los sistemas operativos y máquinas. Su estructura de datos nativa podría ser ligeramente diferente.

La mayoría de estos patrones son malas prácticas que provienen de leer y copiar el código malo existente. A menudo, reflejan malentendidos sobre lo que C requiere o no.

Es similar a #define BEGIN { excepto que guarda algo de escritura en lugar de hacer más.
Es similar a #define FALSE 0 . Si su idea de "byte" es la unidad direccionable más pequeña, char es un byte por definición. Si su idea de "byte" es un octeto, entonces cualquiera de los dos caracteres es el tipo de octeto, o su máquina no tiene un tipo de octeto.
Es una taquigrafía realmente fea para las personas que no pueden tocar el tipo ...
Es un error. Debe ser typedef uint32_t u32; O mejor aún, uint32_t debería ser usado directamente.
Es lo mismo que 4. Reemplace uint32_t con int16_t .

Por favor, ponga un sello " considerado dañino " en todos ellos. typedef debe usarse cuando realmente necesite crear un nuevo tipo cuya definición pueda cambiar a lo largo del ciclo de vida de su código o cuando el código sea portado a un hardware diferente, no porque piense que C sería "más bonito" con nombres de tipos diferentes.

Lo usamos para que sea específico del proyecto / plataforma, todo tiene una convención de nomenclatura común

pname_int32, pname_uint32, pname_uint8 - pname es nombre de proyecto / plataforma / módulo

Y algunos #defines

pname_malloc, pname_strlen

Es más fácil de leer y acorta los tipos de datos largos como el carácter unsigned char a pname_uint8, lo que lo convierte en una convención para todos los módulos.

Al portar, solo tiene que modificar el archivo individual, lo que facilita la portabilidad.

Para abreviar la historia larga, es posible que desee hacerlo para que su código sea portátil (con menos esfuerzo / edición). De esta manera, no depende de ''int'', en su lugar, está utilizando INTEGER que puede ser lo que quiera.

Todos los tipos [|u]intN_t , donde N = 8 | 16 | 32 | 64, etc., se definen por arquitectura de esta manera exacta. Esto es una consecuencia directa del hecho de que el estándar no exige que char , int , float , etc. tengan exactamente N bits, lo que sería una locura. En su lugar, la norma define los valores mínimos y máximos de cada tipo como garantías para el programador, y en varios tipos de arquitecturas pueden exceder esos límites. No es una vista infrecuente.

Los typedef s en su publicación se utilizan para tipos definidos de cierta longitud, en una arquitectura específica. Probablemente no sea la mejor opción para nombrar; u32 y s16 son un poco demasiado cortos, en mi opinión. Además, es algo malo exponer los nombres ulg y uch , uno podría prefijarlos con una cadena específica de la aplicación, ya que obviamente no estarán expuestos.

Espero que esto ayude.