Pour définir un nouveau type de données en C par exemple, un type de liste liée de ce que j'ai vu la pratique commune est La première définition. La question est si la deuxième définition est également une pratique acceptable.
Dans quel cas si cela devrait préférer la seconde sur la première?
À condition que les variables que nous utilisons sont des pointeurs sur structure list_node
Est-il possible de faire les mêmes opérations avec les deux types?
Quels sont les avantages du premier?
On peut utiliser l'une des définitions suivantes
5 Réponses :
envisager d'utiliser à la fois ces deux:
typedef struct list_node Node; typedef Node* ListHead;
Je préfère le premier style, il est donc clair que les types sont des objets et quels types sont des pointeurs. Mais je trouve C indicateurs faciles à comprendre / interpréter, ce qui (apparemment) beaucoup de gens ne le font pas. Donc, si vous pensez que la plupart des personnes qui lisent votre base de code ne comprendront pas les pointeurs, utilisez Typtructex Struct_foo * Pstruct_foo partout, comme l'API Win32 fait.
Je souhaiterais que les utilisateurs de l'API tapent le "*", c'est-à-dire Typedef la structure, pas un pointeur à la structure. Il s'agit du style largement utilisé dans la glib, qui est l'une des piles c plus populaires.
Cela fonctionne bien car il est em> important de savoir si vous avez un pointeur à une structure ou à la structurer elle-même. Par exemple, pouvez-vous stocker NULL dans une variable du type? Si vous masquez qu'un objet est un pointeur, vous devez créer un nil_node spécial ou une autre valeur pour remplacer NULL. Si vous faites simplement un pointeur, les gens peuvent le traiter comme un. P> Un autre avantage important est la possibilité de mettre la définition de la structure réelle quelque part privée, c'est-à-dire dans le fichier .c au lieu de l'en-tête. Vous pouvez mettre uniquement le type de Timedef dans l'en-tête, tout en gardant la structure elle-même opaque aux utilisateurs de l'API. Cela oblige les personnes à utiliser uniquement les méthodes exportées que vous fournissez pour manipuler la structure. Cela signifie également que vous n'avez pas à reconstruire le monde si vous changez les champs de structure. P> Une autre raison de prendre ce chemin est que parfois vous voulez une structure qui peut être copiée, et vous voulez toujours Typedef it. Prenez une chose comme GDKPoint: P> typedef struct MyType MyType;
MyType* my_type_new(void);
void my_type_unref(MyType *t);
void my_type_ref(MyType *t);
Je suis complètement d'accord. Ce n'est généralement pas une bonne idée d'utiliser Typedef pour masquer si un type est un pointeur ou une structure (sauf si vous utilisez des pointeurs opaques pour une interface de bibliothèque). Pour être honnête, je préfère habituellement appeler un struct A struct et éviter le Typedef tout à fait, mais si vous allez Typedef < / code> quelque chose, faites-le la structure et non le pointeur.
Le style des glib utiliserait des camélins pour une structure Typef et des minuscules pour le type primitif Typedef, c'est donc ce qui supprime la nécessité de taper "struct" tout en maintenant les choses claires. conserve également la capacité d'avoir des structures opaques non dans l'en-tête
Tant que l'identifiant indique qu'il est clair que c'est un pointeur, il n'y a aucun préjudice (je préfère personnellement un suffixe ala _pointer ou _PTR, mais tout ce qui convient au projet). Cela dit, pour le code C-seul, il n'y a pas d'avantage réel pour éviter le * . Pour les environnements mixtes C / C ++ ou Pure C ++, j'ai souvent vu l'utilisation de Typedef S à des pointeurs rationalisés / justifiés de faciliter la transition vers, l'utilisation de et la commutation entre les types de pointeur intelligents. Il y a probablement une vérité à cela, même si je ne me suis jamais retrouvé vouloir adopter la pratique.
Typedef int * pTR_int; pTR_int x, y, z;
Programmeur peut être confondu que les trois x, y, z sont d'Int * Type I.e. Pointeurs à int. Mais en réalité, seul X est d'Int * Type Y et Z sont simples int.
parce que pTR_int x, y, z; est égal à int * x, y, z; pas int * x, * y, * z;
Alors, TLEDEF crée également une confusion dans l'esprit des programmeurs et peut conduire à des bogues et des erreurs.
Question similaire: Stackoverflow .com / questions / 3781932 / ...