J'ai vu de nombreux programmes composés de structures comme celle ci-dessous

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

elem user;

Pourquoi est-il si nécessaire? Une raison spécifique ou un domaine applicable?

Comme l'a dit Greg Hewgill, le typedef signifie que vous n'avez plus à écrire structpartout. Cela permet non seulement d'économiser les frappes, mais aussi de rendre le code plus propre car il fournit une abstraction plus smidgen.

Choses 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, il semble plutôt qu'il y ait vraiment un type appelé "Point" dans votre langue. Ce qui, après le typedef, est le cas je suppose.

Notez également que même si votre exemple (et le mien) a omis de nommer le struct lui - même, le nommer est également utile lorsque vous souhaitez fournir un type opaque. Ensuite, vous auriez du code comme celui-ci dans l'en-tête, par exemple:

typedef struct Point Point;

Point * point_new(int x, int y);

puis fournissez la structdéfinition 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 renvoyer la valeur Point par, car sa définition est masquée aux utilisateurs du fichier d'en-tête. C'est une technique largement utilisée dans GTK + , par exemple.

MISE À JOUR Notez qu'il existe également des projets C très appréciés où cette utilisation de typedefto hide structest considérée comme une mauvaise idée, le noyau Linux est probablement le projet le plus connu. Voir le chapitre 5 du document Linux Kernel CodingStyle pour les mots énervés de Linus. :) Mon point est que le "devrait" dans la question n'est peut-être pas gravé dans le marbre, après tout.

C'est incroyable combien de personnes se trompent. S'IL VOUS PLAÎT ne pas typedef structs en C, il pollue inutilement l'espace de noms global qui est généralement très pollué déjà dans les grands programmes C.

En outre, les structures typedef'd sans nom de balise sont une cause majeure d'imposition inutile de relations de classement entre les fichiers d'en-tête.

Considérer:

#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, sans utiliser de typedefs, il est possible pour une unité compiland d'inclure foo.h pour obtenir la FOO_DEFdéfinition. S'il ne tente pas de déréférencer le membre "bar" de la foostructure, il ne sera pas nécessaire 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 du code très lisible tel que:

struct foo *foo;

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

Étant donné que les espaces de noms sont séparés, il n'y a pas de conflit dans les noms de variables coïncidant avec leur nom de balise struct.

Si je dois conserver votre code, je supprimerai vos structures typedef'd.

Extrait d'un ancien article de Dan Saks ( http://www.ddj.com/cpp/184403396?pgno=3 ):

Les règles du langage C pour nommer les structures sont un peu excentriques, mais elles sont assez inoffensives. Cependant, lorsqu'elles sont étendues aux classes en C ++, ces mêmes règles ouvrent de petites fissures pour les bogues à parcourir.

En C, les noms apparaissant dans

struct s
    {
    ...
    };

est une balise. Un nom de balise n'est pas un nom de type. 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 tous les autres noms (pour les fonctions, les types, les variables et les constantes d'énumération). Les compilateurs C conservent les balises dans une table de symboles conceptuellement sinon physiquement séparée de la table contenant 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 la variable s de type struct s. Ce n'est peut-être pas une bonne pratique, mais les compilateurs C doivent l'accepter. Je n'ai jamais vu de raison pour laquelle C a été conçu de cette façon. J'ai toujours pensé que c'était une erreur, mais ça y est.

De nombreux programmeurs (y compris le vôtre) préfèrent considérer les noms de structure comme des noms de type, ils définissent donc un alias pour la balise à l'aide d'un typedef. Par exemple, définir

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 d'un type et d'une variable (ou fonction ou constante d'énumération):

S S;    // error

C'est bon.

Le nom de balise dans une définition de structure, d'union ou d'énumération est facultatif. De nombreux programmeurs replient la définition de la structure dans le typedef et se dispensent complètement de la balise, comme dans:

typedef struct
    {
    ...
    } S;

L'article lié a également une discussion sur la façon dont le comportement C ++ de ne pas exiger un typedefpeut provoquer des problèmes de masquage de nom subtils. Pour éviter ces problèmes, c'est aussi une bonne idée pour typedefvos classes et structures en C ++, même si à première vue cela semble inutile. En C ++, typedefle nom caché devient une erreur dont le compilateur vous parle plutôt qu'une source cachée de problèmes potentiels.

L'utilisation de a typedefévite d'avoir à écrire à structchaque 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

Une autre bonne raison de toujours taper les énumérations et les structures 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)? Ceci se 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, des fautes de frappe similaires auraient entraîné des erreurs de compilation pour l'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 recommanderais TOUJOURS de taper des structures et des énumérations.

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

Le style de codage du noyau Linux Le chapitre 5 présente de grands avantages et inconvénients (principalement des inconvénients) de l'utilisation typedef.

Veuillez ne pas utiliser des choses comme "vps_t".

C'est une erreur d'utiliser typedef pour les structures et les pointeurs. Quand vous voyez un

vps_t a;

dans la source, qu'est-ce que cela signifie?

En revanche, si elle dit

struct virtual_container *a;

vous pouvez réellement dire ce qu'est un "a".

Beaucoup de gens pensent que les typedefs "aident à la lisibilité". Mais non. Ils ne sont utiles que pour:

(a) des objets totalement opaques (où le typedef est activement utilisé pour cacher ce qu'est l'objet).

Exemple: "pte_t" etc. objets opaques auxquels vous ne pouvez accéder qu'en utilisant les fonctions d'accesseur appropriées.

REMARQUE! L'opacité et les «fonctions d'accesseur» ne sont pas bonnes en soi. La raison pour laquelle nous les avons pour des choses comme pte_t etc. est qu'il n'y a vraiment absolument aucune information accessible de manière portable.

(b) Effacer les types entiers, où l'abstraction permet d' éviter toute confusion, qu'elle soit "int" ou "longue".

u8 / u16 / u32 sont des caractères typographiques parfaitement fins, bien qu'ils s'inscrivent mieux dans la catégorie (d) qu'ici.

REMARQUE! Encore une fois - il doit y avoir une raison à cela. Si quelque chose est "non signé longtemps", alors il n'y a aucune raison de le faire

typedef unsigned long myflags_t;

mais s'il existe une raison claire pour laquelle, dans certaines circonstances, il peut s'agir d'un "entier non signé" et dans d'autres configurations, il peut être "non signé long", alors allez-y et utilisez un typedef.

(c) lorsque vous utilisez clairsemé pour créer littéralement un nouveau type pour la vérification de type.

d) Nouveaux types identiques aux types C99 standard, dans certaines circonstances exceptionnelles.

Bien qu'il ne faudrait que peu de temps aux yeux et au cerveau pour s'habituer aux types standard comme «uint32_t», certaines personnes s'opposent quand même à leur utilisation.

Par conséquent, les types 'u8 / u16 / u32 / u64' spécifiques à Linux et leurs équivalents signés qui sont identiques aux types standard sont autorisés - bien qu'ils ne soient pas obligatoires dans votre nouveau code.

Lorsque vous modifiez un code existant qui utilise déjà l'un ou l'autre ensemble de types, vous devez vous conformer aux choix existants dans ce code.

(e) Types sûrs pour une utilisation dans l'espace utilisateur.

Dans certaines structures qui sont visibles pour l'espace utilisateur, nous ne pouvons pas exiger de types C99 et ne pouvons pas utiliser le formulaire 'u32' ci-dessus. Ainsi, nous utilisons __u32 et des types similaires dans toutes les structures partagées avec l'espace utilisateur.

Il y a peut-être d'autres cas aussi, mais la règle devrait être de ne JAMAIS utiliser un typedef à moins que vous ne puissiez clairement correspondre à l'une de ces règles.

En général, un pointeur ou une structure contenant des éléments auxquels on peut raisonnablement accéder directement ne doit jamais être un typedef.

Il s'avère qu'il y a des avantages et des inconvénients. Une source d'information utile est le livre fondateur "Expert C Programming" ( Chapitre 3 ). En bref, en C, vous avez plusieurs espaces de noms: balises, types, noms de membres et identificateurs . typedefintroduit un alias pour un type et le localise dans l'espace de noms des balises. À savoir,

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

définit deux choses. Une balise dans l'espace de noms de balise et un type dans l'espace de noms de type. Vous pouvez donc faire les deux Type myTypeet struct Tag myTagType. Les déclarations comme struct Type myTypeou Tag myTagTypesont illégales. De plus, dans une déclaration comme celle-ci:

typedef Type *Type_ptr;

nous définissons un pointeur sur notre type. Donc, si nous déclarons:

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

puis var1, var2et myTagType1sont des pointeurs vers Type mais myTagType2pas.

Dans le livre mentionné ci-dessus, il mentionne que les structures typedefing ne sont pas très utiles car cela évite au programmeur d'écrire le mot struct. Cependant, j'ai une objection, comme beaucoup d'autres programmeurs C. Bien que cela tourne parfois pour obscurcir certains noms (c'est pourquoi il n'est pas recommandé dans les grandes bases de code comme le noyau) lorsque vous souhaitez implémenter le polymorphisme en C, cela aide beaucoup de gens à chercher ici des détails . Exemple:

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

tu peux faire:

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

Vous pouvez donc accéder à un membre externe ( flags) par la structure interne ( MyPipe) via la conversion. Pour moi, il est moins déroutant de convertir le type entier que de le faire (struct MyWriter_ *) s;chaque fois que vous souhaitez effectuer une telle fonctionnalité. Dans ces cas, un bref référencement est un gros problème, surtout si vous utilisez fortement la technique dans votre code.

Enfin, le dernier aspect des typedeftypes ed est l'incapacité de les étendre, contrairement aux macros. Si par exemple, vous avez:

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

vous pouvez alors déclarer

unsigned X x; but not
unsigned Y y;

Nous ne nous soucions pas vraiment de cela pour les structures, car cela ne s'applique pas aux spécificateurs de stockage ( volatileet const).

Je ne pense pas que des déclarations prospectives soient même possibles avec typedef. L'utilisation de struct, enum et union permet de transmettre des déclarations lorsque les dépendances (connaissent) sont bidirectionnelles.

Style: L'utilisation de typedef en C ++ est assez logique. Cela peut presque être nécessaire lorsqu'il s'agit de modèles qui nécessitent des paramètres multiples et / ou variables. Le typedef aide à garder la dénomination droite.

Ce n'est pas le cas dans le langage de programmation C. Le plus souvent, l'utilisation de typedef n'a d'autre but que d'obscurcir l'utilisation de la structure de données. Étant donné que seuls {struct (6), enum (4), union (5)} nombre de touches sont utilisés pour déclarer un type de données, il n'y a presque aucune utilité pour l'aliasing de la structure. Ce type de données est-il une union ou une structure? L'utilisation de la déclaration non typée simple vous permet de savoir immédiatement de quel type il s'agit.

Remarquez comment Linux est écrit en évitant strictement cet aliasing de non-sens typedef. Le résultat est un style minimaliste et épuré.

Commençons par les bases et progressons.

Voici un exemple de définition de structure:

struct point
  {
    int x, y;
  };

Ici, le nom pointest facultatif.

Une Structure peut être déclarée lors de sa définition ou après.

Déclaration lors de la définition

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

Déclarer après la définition

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

Maintenant, notez attentivement le dernier cas ci-dessus; vous devez écrire struct pointpour déclarer des structures de ce type si vous décidez de créer ce type à un stade ultérieur de votre code.

Entrez typedef. Si vous avez l'intention de créer une nouvelle structure (la structure est un type de données personnalisé) ultérieurement dans votre programme en utilisant le même plan, l'utilisation typedeflors de sa définition peut être une bonne idée car vous pouvez économiser de la frappe à l'avenir.

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

Points first_point, second_point;

Un mot de prudence lors de la désignation de votre type personnalisé

Rien ne vous empêche d'utiliser le suffixe _t à la fin de votre nom de type personnalisé, mais POSIX standard réserve l'utilisation du suffixe _t pour désigner les noms de type de bibliothèque standard.

le nom que vous donnez (facultativement) à la structure s'appelle le nom de la balise et, comme cela a été noté, n'est pas un type en soi. Pour accéder au type, le préfixe struct est requis.

GTK + à part, je ne suis pas sûr que le nom de variable soit utilisé aussi couramment qu'un typedef pour le type de structure, donc en C ++ qui est reconnu et vous pouvez omettre le mot-clé struct et utiliser le nom de variable comme nom de type également:

    struct MyStruct
    {
      int i;
    };

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

typedef ne fournira pas un ensemble de structures de données co-dépendantes. Vous ne pouvez pas faire cela avec typdef:

struct bar;
struct foo;

struct foo {
    struct bar *b;
};

struct bar {
    struct foo *f;
};

Bien sûr, vous pouvez toujours ajouter:

typedef struct foo foo_t;
typedef struct bar bar_t;

Quel est exactement l'intérêt de cela?

A> a typdef aide à la signification et à la documentation d'un programme en permettant la création de synonymes plus significatifs pour les types de données . De plus, ils aident à paramétrer un programme contre les problèmes de portabilité (K&R, pg147, C prog lang).

B> une structure définit un type . Structs permet un regroupement pratique d'une collection de vars pour faciliter la manipulation (K&R, pg127, C prog lang.) En une seule unité

C> typedef'ing un struct est expliqué dans A ci-dessus.

D> Pour moi, les structures sont des types ou conteneurs personnalisés ou des collections ou des espaces de noms ou des types complexes, tandis qu'un typdef n'est qu'un moyen de créer plus de surnoms.

Il s'avère que le typedef C99 est requis. Il est obsolète, mais de nombreux outils (ala HackRank) utilisent c99 comme implémentation C pure. Et typedef y est requis.

Je ne dis pas qu'ils devraient changer (peut-être avoir deux options C) si l'exigence changeait, ceux d'entre nous qui étudient pour des entrevues sur le site seraient SOL.

Dans le langage de programmation «C», le mot-clé «typedef» est utilisé pour déclarer un nouveau nom pour un objet (type struct, tableau, fonction..enum). Par exemple, je vais utiliser un «struct-s». Dans «C», nous déclarons souvent un «struct» en dehors de la fonction «principale». Par exemple:

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

}

Chaque fois que je décide d'utiliser un type de struct, j'ai besoin de ce mot-clé 'struct' quelque chose '' nom '.' Typedef 'renommera simplement ce type et je peux utiliser ce nouveau nom dans mon programme chaque fois que je le souhaite. Notre code sera donc:

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 vous avez un objet local (struct, tableau, précieux) qui sera utilisé dans l'ensemble de votre programme, vous pouvez simplement lui donner un nom en utilisant un 'typedef'.

Du tout, en langage C, struct / union / enum sont des macro-instructions traitées par le préprocesseur du langage C (ne vous trompez pas avec le préprocesseur qui traite "#include" et autres)

donc :

struct a
{
   int i;
};

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

struct b est dépensé comme quelque chose comme ceci:

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

et donc, au moment de la compilation, il évolue sur la pile comme quelque chose comme: b: int ai int i int j

c'est aussi pourquoi il est difficile d'avoir des structures auto-référentes, un préprocesseur C rond dans une boucle de déclaration qui ne peut pas se terminer.

typedef est un spécificateur de type, cela signifie que seul le compilateur C le traite et qu'il peut faire ce qu'il veut pour optimiser l'implémentation du code assembleur. Il ne dépense pas non plus stupidement un membre de type comme le fait le préprocesseur avec les structures mais utilise un algorithme de construction de référence plus complexe, donc une construction comme:

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

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

est autorisé et entièrement fonctionnel. Cette implémentation donne également accès à la conversion de type compilateur et supprime certains effets de bogue lorsque le thread d'exécution quitte le champ d'application des fonctions d'initialisation.

Cela signifie qu'en C, les typedefs sont plus proches de la classe C ++ que des structures solitaires.