Pourquoi devrions-nous typedef un struct si souvent en C ?

Question

J'ai vu de nombreux programmes constitués de structures comme celle qui suit

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

elem user;

Pourquoi en a-t-on besoin si souvent ? Une raison spécifique ou un domaine d'application ?

Answer 1

Comme l'a dit Greg Hewgill, le typedef signifie que vous ne devez plus écrire struct partout. Cela permet non seulement d'économiser des frappes au clavier, mais aussi de rendre le code plus propre puisqu'il fournit un peu plus d'abstraction.

Des trucs comme

typedef struct {
  int x, y;
} Point;

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

devient plus propre lorsque vous n'avez pas besoin de voir le mot-clé "struct" partout, cela ressemble plus à s'il y a vraiment un type appelé "Point" dans votre langage. Ce qui, après le typedef c'est le cas je suppose.

Notez également que, bien que votre exemple (et le mien) ait omis de nommer l'élément struct Le fait de le nommer est également utile lorsque vous souhaitez fournir un type opaque. Vous auriez alors du code comme celui-ci dans l'en-tête, par exemple :

typedef struct Point Point;

Point * point_new(int x, int y);

et ensuite fournir le struct dans le fichier d'implémentation :

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;
}

Dans ce dernier cas, vous ne pouvez pas retourner le point par valeur, puisque sa définition est cachée aux utilisateurs du fichier d'en-tête. Il s'agit d'une technique largement utilisée dans GTK+ par exemple.

UPDATE Il convient de noter qu'il existe également des projets C très réputés où cette utilisation de la fonction typedef pour cacher struct est considéré comme une mauvaise idée, le noyau Linux est probablement le projet de ce type le plus connu. Voir le chapitre 5 de Le document CodingStyle du noyau Linux pour les mots de colère de Linus. :) Mon point de vue est que le "devrait" dans le q

Answer 2

C'est incroyable le nombre de personnes qui se trompent à ce sujet. S'il vous plaît, ne faites pas de typedef structs en C, cela pollue inutilement l'espace de noms global qui est déjà très pollué dans les grands programmes C.

De même, les structures typées sans nom de balise sont une cause majeure de l'imposition inutile de relations d'ordre entre les fichiers d'en-tête.

Pensez-y :

#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

Avec une telle définition, qui n'utilise pas de typedefs, il est possible pour une unité compilatrice d'inclure foo.h pour obtenir le fichier FOO_DEF définition. S'il ne tente pas de déréférencer le membre 'bar' de la définition de foo struct alors il n'y aura pas besoin d'inclure le fichier "bar.h".

De plus, comme les espaces de noms sont différents entre les noms de balises et les noms de membres, il est possible d'écrire un code très lisible tel que :

struct foo *foo;

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

Puisque les espaces de noms sont séparés, il n'y a pas de conflit à nommer les variables en même temps que le nom de leur balise struct.

Si je dois maintenir votre code, je supprimerai vos structs typés.

Answer 3

D'après un ancien article de Dan Saks ( http://www.ddj.com/cpp/184403396?pgno=3 ) :

---

Les règles du langage C pour nommer structs sont un peu excentriques, mais elles sont plutôt inoffensives. Cependant, lorsqu'elles sont étendues aux classes en C++, ces mêmes règles ouvrent de petites fissures dans lesquelles les bogues se faufiler à travers.

En C, le nom s apparaissant dans

struct s
    {
    ...
    };

est une balise. Un nom de balise n'est pas un nom de type nom. Compte tenu de la définition ci-dessus, des déclarations telles que

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

sont des erreurs en C. Vous devez les écrire comme

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

Les noms des unions et des énumérations sont également des balises plutôt que des types.

En C, les balises sont distinctes de toutes les autres noms (pour les fonctions, les types variables et constantes d'énumération). Les compilateurs C maintiennent les balises dans une table symbole qui est conceptuellement, sinon physiquement séparée de la table qui contient tous les autres noms. Ainsi, il est possible pour un programme C d'avoir à la fois une balise et un autre nom avec la même orthographe dans la même portée. Par exemple,

struct s s;

est une déclaration valide qui déclare variable s de type struct s. Cela peut pas une bonne pratique, mais les compilateurs C doivent l'accepter. Je n'ai jamais vu une raison pour laquelle le C a été conçu de cette ainsi. J'ai toujours pensé que c'était une erreur, mais c'est ainsi.

De nombreux programmeurs (dont le vôtre moi) préfèrent penser aux noms de structures comme des noms de type, donc ils définissent un alias pour la balise en utilisant un typedef. Pour exemple, en définissant

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

vous permet d'utiliser S à la place de struct s, comme dans

S x;
S *p;

Un programme ne peut pas utiliser S comme nom de à la fois d'un type et d'une variable (ou fonction ou constante d'énumération) :

S S;    // error

C'est bien.

Le nom de la balise dans une structure, une union, ou une ou d'un enum est facultatif. De nombreux programmeurs programmeurs plient la définition de la structure dans le typedef et se passent de la balise comme dans :

typedef struct
    {
    ...
    } S;

---

L'article lié contient également une discussion sur la façon dont le comportement du C++, qui consiste à ne pas exiger d'un typedef peut causer de subtils problèmes de dissimulation de noms. Pour éviter ces problèmes, il est conseillé de typedef vos classes et structs en C++ également, même si, à première vue, cela semble inutile. En C++, avec le typedef le masquage du nom devient une erreur dont le compilateur vous parle plutôt qu'une source cachée de problèmes potentiels.

Answer 4

Utilisation d'un typedef évite de devoir écrire struct chaque fois que vous déclarez une variable de ce type :

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

Answer 5

Une autre bonne raison de toujours typedef enums et structs résulte de ce problème :

enum EnumDef
{
  FIRST_ITEM,
  SECOND_ITEM
};

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

Remarquez la faute de frappe dans EnumDef dans la structure (Enu u mDef) ? Cela compile sans erreur (ou avertissement) et est (selon l'interprétation littérale de la norme C) correct. Le problème est que je viens de créer une nouvelle définition d'énumération (vide) dans ma structure. Je n'utilise pas (comme prévu) la définition précédente EnumDef.

Avec un typdef, ce type de typos aurait entraîné une erreur de compilation pour utilisation d'un type inconnu :

typedef 
{
  FIRST_ITEM,
  SECOND_ITEM
} EnumDef;

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

Je préconise de TOUJOURS typographier les structures et les énumérations.

Non seulement pour économiser de la frappe (sans jeu de mots ;)), mais aussi parce que c'est plus sûr.