He visto muchos programas que consisten en estructuras como la siguiente

typedef struct 
{
    int i;
    char k;
} elem;

elem user;

¿Por qué se necesita con tanta frecuencia? ¿Alguna razón específica o área aplicable?

Como dijo Greg Hewgill, el typedef significa que ya no tienes que escribir por structtodas partes. Eso no solo ahorra pulsaciones de teclas, sino que también puede hacer que el código sea más limpio, ya que proporciona una pizca más abstracción.

Cosas como

typedef struct {
  int x, y;
} Point;

Point point_new(int x, int y)
{
  Point a;
  a.x = x;
  a.y = y;
  return a;
}

se vuelve más limpio cuando no necesita ver la palabra clave "struct" en todo el lugar, parece más como si realmente hubiera un tipo llamado "Point" en su idioma. Lo cual, después del typedef, es el caso, supongo.

También tenga en cuenta que si bien su ejemplo (y el mío) omitió nombrar a struct sí mismo, en realidad nombrarlo también es útil para cuando desea proporcionar un tipo opaco. Entonces tendría un código como este en el encabezado, por ejemplo:

typedef struct Point Point;

Point * point_new(int x, int y);

y luego proporcione la structdefinición en el archivo de implementación:

struct Point
{
  int x, y;
};

Point * point_new(int x, int y)
{
  Point *p;
  if((p = malloc(sizeof *p)) != NULL)
  {
    p->x = x;
    p->y = y;
  }
  return p;
}

En este último caso, no puede devolver el Punto por valor, ya que su definición está oculta para los usuarios del archivo de encabezado. Esta es una técnica utilizada ampliamente en GTK + , por ejemplo.

ACTUALIZACIÓN Tenga en cuenta que también hay proyectos C de gran prestigio en los que este uso de typedefocultar structse considera una mala idea, el kernel de Linux es probablemente el proyecto más conocido. Vea el Capítulo 5 del documento Linux Kernel CodingStyle para las palabras de enojo de Linus. :) Mi punto es que el "debería" en la pregunta quizás no esté escrito en piedra, después de todo.

Es sorprendente cuántas personas se equivocan. POR FAVOR, no escriba las estructuras de definición en C, ya que contamina innecesariamente el espacio de nombres global, que normalmente ya está muy contaminado en los grandes programas de C.

Además, las estructuras typedef'd sin un nombre de etiqueta son una causa importante de la imposición innecesaria de relaciones de orden entre los archivos de encabezado.

Considerar:

#ifndef FOO_H
#define FOO_H 1

#define FOO_DEF (0xDEADBABE)

struct bar; /* forward declaration, defined in bar.h*/

struct foo {
  struct bar *bar;
};

#endif

Con tal definición, sin usar typedefs, es posible que una unidad compiland incluya foo.h para llegar a la FOO_DEFdefinición. Si no intenta desreferenciar al miembro 'bar' de la fooestructura, entonces no será necesario incluir el archivo "bar.h".

Además, dado que los espacios de nombres son diferentes entre los nombres de etiqueta y los nombres de miembros, es posible escribir código muy legible como:

struct foo *foo;

printf("foo->bar = %p", foo->bar);

Como los espacios de nombres están separados, no hay conflicto en nombrar variables que coincidan con su nombre de etiqueta de estructura.

Si tengo que mantener su código, eliminaré sus estructuras typedef'd.

De un artículo antiguo de Dan Saks ( http://www.ddj.com/cpp/184403396?pgno=3 ):

Las reglas del lenguaje C para nombrar estructuras son un poco excéntricas, pero son bastante inofensivas. Sin embargo, cuando se extiende a las clases en C ++, esas mismas reglas abren pequeñas grietas para que los errores puedan rastrearse.

En C, el nombre aparece en

struct s
    {
    ...
    };

es una etiqueta Un nombre de etiqueta no es un nombre de tipo. Dada la definición anterior, declaraciones como

s x;    /* error in C */
s *p;   /* error in C */

son errores en C. Debes escribirlos como

struct s x;     /* OK */
struct s *p;    /* OK */

Los nombres de uniones y enumeraciones también son etiquetas en lugar de tipos.

En C, las etiquetas son distintas de todos los demás nombres (para funciones, tipos, variables y constantes de enumeración). Los compiladores de C mantienen etiquetas en una tabla de símbolos que es conceptualmente, si no físicamente, separada de la tabla que contiene todos los demás nombres. Por lo tanto, es posible que un programa en C tenga una etiqueta y otro nombre con la misma ortografía en el mismo alcance. Por ejemplo,

struct s s;

es una declaración válida que declara variables s de tipo struct s. Puede que no sea una buena práctica, pero los compiladores de C deben aceptarlo. Nunca he visto una justificación de por qué C fue diseñado de esta manera. Siempre he pensado que fue un error, pero ahí está.

Muchos programadores (incluido el suyo de verdad) prefieren pensar en los nombres de estructura como nombres de tipo, por lo que definen un alias para la etiqueta utilizando un typedef. Por ejemplo, definiendo

struct s
    {
    ...
    };
typedef struct s S;

le permite usar S en lugar de struct s, como en

S x;
S *p;

Un programa no puede usar S como el nombre de un tipo y una variable (o función o constante de enumeración):

S S;    // error

Esto es bueno.

El nombre de la etiqueta en una definición de estructura, unión o enumeración es opcional. Muchos programadores pliegan la definición de estructura en typedef y prescinden de la etiqueta por completo, como en:

typedef struct
    {
    ...
    } S;

El artículo vinculado también tiene una discusión sobre cómo el comportamiento de C ++ de no requerir un typedefpuede causar problemas sutiles para ocultar nombres. Para evitar estos problemas, también es una buena idea para typedefsus clases y estructuras en C ++, aunque a primera vista parezca innecesario. En C ++, con el typedefnombre oculto se convierte en un error que el compilador le informa en lugar de una fuente oculta de posibles problemas.

Usar a typedefevita tener que escribir structcada vez que declaras una variable de ese tipo:

struct elem
{
 int i;
 char k;
};
elem user; // compile error!
struct elem user; // this is correct

Otra buena razón para escribir siempre enumeraciones y estructuras resulta de este problema:

enum EnumDef
{
  FIRST_ITEM,
  SECOND_ITEM
};

struct StructDef
{
  enum EnuumDef MyEnum;
  unsigned int MyVar;
} MyStruct;

Observe el error tipográfico en EnumDef en la estructura (Enu u mDef)? Esto se compila sin error (o advertencia) y es (dependiendo de la interpretación literal del Estándar C) correcto. El problema es que acabo de crear una nueva definición de enumeración (vacía) dentro de mi estructura. No estoy (según lo previsto) usando la definición anterior EnumDef.

Con un error tipográfico similar, los errores tipográficos habrían provocado errores de compilación al usar un tipo desconocido:

typedef 
{
  FIRST_ITEM,
  SECOND_ITEM
} EnumDef;

typedef struct
{
  EnuumDef MyEnum; /* compiler error (unknown type) */
  unsigned int MyVar;
} StructDef;
StrructDef MyStruct; /* compiler error (unknown type) */

Yo recomendaría SIEMPRE estructuras y enumeraciones de tipografía.

No solo para guardar algo de escritura (sin juego de palabras;)), sino porque es más seguro.

El Capítulo 5 del estilo de codificación del kernel de Linux ofrece excelentes ventajas y desventajas (principalmente contras) de uso typedef.

Por favor, no use cosas como "vps_t".

Es un error usar typedef para estructuras y punteros. Cuando veas un

vps_t a;

en la fuente, ¿qué significa?

Por el contrario, si dice

struct virtual_container *a;

en realidad puedes decir qué es "a".

Mucha gente piensa que typedefs "ayuda a la legibilidad". No tan. Son útiles solo para:

(a) objetos totalmente opacos (donde typedef se usa activamente para ocultar lo que es el objeto).

Ejemplo: "pte_t", etc., objetos opacos a los que solo puede acceder utilizando las funciones de acceso adecuadas.

¡NOTA! La opacidad y las "funciones de acceso" no son buenas en sí mismas. La razón por la que los tenemos para cosas como pte_t etc es que realmente es absolutamente cero información de manera portátil puede acceder allí.

(b) Tipos enteros claros, donde la abstracción ayuda a evitar confusiones si es "int" o "largo".

u8 / u16 / u32 son tipos de letra perfectamente precisos, aunque encajan en la categoría (d) mejor que aquí.

¡NOTA! Nuevamente, debe haber una razón para esto. Si algo es "sin firmar por mucho tiempo", entonces no hay razón para hacerlo

typedef unsigned long myflags_t;

pero si hay una razón clara de por qué bajo ciertas circunstancias podría ser un "unsigned int" y bajo otras configuraciones podría ser "unsigned long", entonces, por supuesto, siga adelante y use typedef.

(c) cuando usa disperso para crear literalmente un nuevo tipo para la verificación de tipo.

(d) Nuevos tipos que son idénticos a los tipos C99 estándar, en ciertas circunstancias excepcionales.

Aunque solo tomaría poco tiempo para que los ojos y el cerebro se acostumbren a los tipos estándar como 'uint32_t', algunas personas se oponen a su uso de todos modos.

Por lo tanto, los tipos específicos de Linux 'u8 / u16 / u32 / u64' y sus equivalentes firmados que son idénticos a los tipos estándar están permitidos, aunque no son obligatorios en el nuevo código propio.

Al editar el código existente que ya usa uno u otro conjunto de tipos, debe ajustarse a las opciones existentes en ese código.

(e) Tipos seguros para usar en el espacio de usuario.

En ciertas estructuras que son visibles para el espacio de usuario, no podemos requerir tipos C99 y no podemos usar el formulario 'u32' anterior. Por lo tanto, usamos __u32 y tipos similares en todas las estructuras que se comparten con el espacio de usuario.

Tal vez también haya otros casos, pero la regla debería ser NUNCA utilizar un typedef a menos que pueda coincidir claramente con una de esas reglas.

En general, un puntero o una estructura que tenga elementos a los que se pueda acceder directamente de manera razonable nunca debe ser un typedef.

Resulta que hay pros y contras. Una fuente útil de información es el libro seminal "Programación Expert C" ( Capítulo 3 ). Brevemente, en C tiene múltiples espacios de nombres: etiquetas, tipos, nombres de miembros e identificadores . typedefintroduce un alias para un tipo y lo ubica en el espacio de nombres de la etiqueta. A saber,

typedef struct Tag{
...members...
}Type;

define dos cosas Una etiqueta en el espacio de nombres de etiqueta y un tipo en el espacio de nombres de tipo. Por lo que puede hacer ambas cosas Type myTypey struct Tag myTagType. Declaraciones como struct Type myTypeo Tag myTagTypeson ilegales. Además, en una declaración como esta:

typedef Type *Type_ptr;

definimos un puntero a nuestro tipo. Entonces si declaramos:

Type_ptr var1, var2;
struct Tag *myTagType1, myTagType2;

entonces var1, var2y myTagType1son punteros a Tipo pero myTagType2no.

En el libro mencionado anteriormente, menciona que las estructuras de definición de texto no son muy útiles, ya que solo evita que el programador escriba la palabra struct. Sin embargo, tengo una objeción, como muchos otros programadores de C. Aunque a veces se vuelve para ofuscar algunos nombres (es por eso que no es aconsejable en bases de código grandes como el núcleo) cuando se quiere implementar el polimorfismo en C, ayuda mucho mirar aquí para más detalles . Ejemplo:

typedef struct MyWriter_t{
    MyPipe super;
    MyQueue relative;
    uint32_t flags;
...
}MyWriter;

tu puedes hacer:

void my_writer_func(MyPipe *s)
{
    MyWriter *self = (MyWriter *) s;
    uint32_t myFlags = self->flags;
...
}

Por lo tanto, puede acceder a un miembro externo ( flags) mediante la estructura interna ( MyPipe) a través de la conversión. Para mí es menos confuso lanzar todo el tipo que hacer(struct MyWriter_ *) s; cada vez que desee realizar dicha funcionalidad. En estos casos, las referencias breves son importantes, especialmente si emplea la técnica en su código.

Finalmente, el último aspecto con los typedeftipos ed es la incapacidad de extenderlos, en contraste con las macros. Si, por ejemplo, tienes:

#define X char[10] or
typedef char Y[10]

entonces puedes declarar

unsigned X x; but not
unsigned Y y;

Realmente no nos interesan las estructuras porque no se aplica a los especificadores de almacenamiento ( volatiley const).

No creo que las declaraciones futuras sean posibles con typedef. El uso de struct, enum y union permite reenviar declaraciones cuando las dependencias (sabe) son bidireccionales.

Estilo: el uso de typedef en C ++ tiene bastante sentido. Casi puede ser necesario cuando se trata de plantillas que requieren parámetros múltiples y / o variables. El typedef ayuda a mantener el nombre directo.

No es así en el lenguaje de programación C. El uso de typedef con mayor frecuencia no tiene otro propósito que ofuscar el uso de la estructura de datos. Dado que solo se utilizan {struct (6), enum (4), union (5)} número de pulsaciones de teclas para declarar un tipo de datos, casi no se utiliza el aliasing de la estructura. ¿Es ese tipo de datos una unión o una estructura? El uso de la declaración directa no tipificada le permite saber de inmediato de qué tipo es.

Observe cómo se escribe Linux evitando estrictamente este aliasing sin sentido que typedef trae. El resultado es un estilo minimalista y limpio.

Comencemos con lo básico y avancemos.

Aquí hay un ejemplo de definición de estructura:

struct point
  {
    int x, y;
  };

Aqui el nombre point es opcional.

Una estructura puede declararse durante su definición o después.

Declarando durante la definición

struct point
  {
    int x, y;
  } first_point, second_point;

Declarando después de la definición

struct point
  {
    int x, y;
  };
struct point first_point, second_point;

Ahora, observe cuidadosamente el último caso anterior; necesitas escribirstruct point para declarar estructuras de ese tipo si decide crear ese tipo más adelante en su código.

Introduzca typedef. Si tiene la intención de crear una nueva Estructura (la Estructura es un tipo de datos personalizado) más adelante en su programa usando el mismo modelo, usarlo typedefdurante su definición podría ser una buena idea ya que puede guardar algo de escritura en adelante.

typedef struct point
  {
    int x, y;
  } Points;

Points first_point, second_point;

Una palabra de precaución al nombrar su tipo personalizado

Nada le impide usar el sufijo _t al final de su nombre de tipo personalizado, pero el estándar POSIX se reserva el uso del sufijo _t para denotar nombres de tipo de biblioteca estándar.

el nombre que (opcionalmente) le da a la estructura se llama nombre de etiqueta y, como se ha señalado, no es un tipo en sí mismo. Para llegar al tipo requiere el prefijo struct.

Dejando a un lado GTK +, no estoy seguro de que el nombre de etiqueta se use de manera tan común como typedef para el tipo de estructura, por lo que en C ++ eso se reconoce y puede omitir la palabra clave de estructura y usar el nombre de etiqueta como nombre de tipo también:

    struct MyStruct
    {
      int i;
    };

    // The following is legal in C++:
    MyStruct obj;
    obj.i = 7;

typedef no proporcionará un conjunto de estructuras de datos co-dependientes. Esto no se puede hacer con typdef:

struct bar;
struct foo;

struct foo {
    struct bar *b;
};

struct bar {
    struct foo *f;
};

Por supuesto, siempre puedes agregar:

typedef struct foo foo_t;
typedef struct bar bar_t;

¿Cuál es exactamente el punto de eso?

A> a typdef ayuda en el significado y la documentación de un programa al permitir la creación de sinónimos más significativos para los tipos de datos . Además, ayudan a parametrizar un programa contra problemas de portabilidad (K&R, pg147, C prog lang).

B> una estructura define un tipo . Structs permite la agrupación conveniente de una colección de vars para la comodidad de manejo (K&R, pg127, C prog lang.) Como una sola unidad

C> typedef'ing a struct se explica en A arriba.

D> Para mí, las estructuras son tipos o contenedores personalizados o colecciones o espacios de nombres o tipos complejos, mientras que un typdef es solo un medio para crear más apodos.

Resulta que en C99 se requiere typedef. Está desactualizado, pero muchas herramientas (ala HackRank) usan c99 como su implementación pura de C. Y typedef se requiere allí.

No estoy diciendo que deberían cambiar (tal vez tener dos opciones de C) si el requisito cambiara, aquellos de nosotros que estudiemos para entrevistas en el sitio sería SOL.

En el lenguaje de programación 'C', la palabra clave 'typedef' se usa para declarar un nuevo nombre para algún objeto (estructura, matriz, función ... tipo de enumeración). Por ejemplo, usaré una 'estructura-s'. En 'C' a menudo declaramos una 'estructura' fuera de la función 'principal'. Por ejemplo:

struct complex{ int real_part, img_part }COMPLEX;

main(){

 struct KOMPLEKS number; // number type is now a struct type
 number.real_part = 3;
 number.img_part = -1;
 printf("Number: %d.%d i \n",number.real_part, number.img_part);

}

Cada vez que decida usar un tipo de estructura necesitaré esta palabra clave 'struct' algo '' nombre '.' Typedef 'simplemente cambiará el nombre de ese tipo y puedo usar ese nuevo nombre en mi programa cada vez que lo desee. Entonces nuestro código será:

typedef struct complex{int real_part, img_part; }COMPLEX;
//now COMPLEX is the new name for this structure and if I want to use it without
// a keyword like in the first example 'struct complex number'.

main(){

COMPLEX number; // number is now the same type as in the first example
number.real_part = 1;
number.img)part = 5;
printf("%d %d \n", number.real_part, number.img_part);

}

Si tiene algún objeto local (estructura, matriz, valioso) que se utilizará en todo su programa, simplemente puede darle un nombre usando un 'typedef'.

En absoluto, en lenguaje C, struct / union / enum son macroinstrucciones procesadas por el preprocesador de lenguaje C (no se confunda con el preprocesador que trata "#include" y otros)

entonces :

struct a
{
   int i;
};

struct b
{
   struct a;
   int i;
   int j;
};

struct b se gasta de la siguiente manera:

struct b
{
    struct a
    {
        int i;
    };
    int i;
    int j;
}

y así, en tiempo de compilación evoluciona en la pila como algo así como: b: int ai int i int j

por eso también es difícil tener estructuras autorreferenciales, el preprocesador C se redondea en un ciclo de declaración que no puede terminar.

typedef son type specifier, eso significa que solo el compilador C lo procesa y puede hacer lo que quiera para optimizar la implementación del código ensamblador. Tampoco gasta miembro de tipo par estúpidamente como lo hace un procesador previo con estructuras, pero usa un algoritmo de construcción de referencia más complejo, por lo que construcción como:

typedef struct a A; //anticipated declaration for member declaration

typedef struct a //Implemented declaration
{
    A* b; // member declaration
}A;

Está permitido y totalmente funcional. Esta implementación también da acceso a la conversión de tipo compilador y elimina algunos efectos de error cuando el hilo de ejecución abandona el campo de aplicación de las funciones de inicialización.

Esto significa que en C typedefs están más cerca como clase de C ++ que en estructuras solitarias.