Discussion :

[Bktero]

Bonjour !

Le titre résume la question.

Avec mon collègue stagiaire, on essaye de définir un maximum de noms symboliques pour décrire les valeurs possibles pour certaines valeurs. Cela permet un code plus lisible. Jusque là, normal

Là où on commence à se poser des questions, c'est de savoir s'il est plus intéressant d'utiliser une série de "#define" ou un "typedef enum" pour lister les valeurs possibles. La liste pour une variable donnée est assez longue. Je précise qu'on travaille sur des systèmes embarqués (micro-controleur PIC de chez Microchip) et qu'on se demande su l'une permet un gain de vitesse d'exécution et/ou de place en mémoire programme?

Quel est l'intérêt de l'un par rapport à l'autre ?


Merci d'avance !



PS: j'ai lu ces deux pages, elles ne m'ont pas aidé ^^
http://c.developpez.com/cours/bernar...hp#enumeration
http://c.developpez.com/cours/bernar...gne/node92.php

[ram-0000]

A mon avis, il n'y a aucun gain côté performance ou taille du binaire.

Le gros plus est plutôt au niveau de la lecture ou du debuggage. Je préfère une fonction

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

error_t GetLastError(void)

plutôt qu'une fonction

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

int GetLastError(void).

C'est plus facile à lire et a comprendre (même si cela fait la même chose).

De plus, les debuggeurs savent afficher le code symbolique d'une énumeration et c'est plus rapide à diagnostiquer un "InvalidParam" que "12" dans le debugger.

[Invité(e)]

De plus, en cas d'erreur dans la définition, soit des macro, soit de l'énumération, le compilateur aura un message plus clair et plus localisé dans le second cas.

[LittleWhite]

Bonjour,

Il faut juste ce rappeler d'une chose. L'enum va empecher de passer deux flags à la fois, en paramètre d'un fonction ( avec le | logique ).
Je dis ça, vous pouvez me prendre pour un idiot, mais lorsque j'avais commencé un code, je pensais que les enums c'était bien ( car restriction dans le choix des valeurs, le compilateur nous empêche de faire trop de betises )... mais au moment ou j'ai eu besoin de passe E1 | E2 , donc deux valeurs différentes de mon enum ... j'ai du remplacé par le define.

Je me répète un peu, le problème du define est que si l'utilisateur passe '42' alors qu'il n'y a aucun define avec la valeur 42 ... et bah le compilateur ne dira rien ( logique )
Donc ... pour moi ... un enum, c'est toujours mieux si on veut se pencher sur le restriction des valeurs que l'on peut passer. ( Soit, si on veut avoir le compilateur qui nous aide )

[diogene]

-

Il faut juste ce rappeler d'une chose. L'enum va empecher de passer deux flags à la fois, en paramètre d'un fonction ( avec le | logique ).

Il suffit de définir la valeur des termes de l'enum comme on le fait par #define

-

Je me répète un peu, le problème du define est que si l'utilisateur passe '42' alors qu'il n'y a aucun define avec la valeur 42 ... et bah le compilateur ne dira rien ( logique )
Donc ... pour moi ... un enum, c'est toujours mieux si on veut se pencher sur le restriction des valeurs que l'on peut passer. ( Soit, si on veut avoir le compilateur qui nous aide )

Le compilateur n'est d'aucun secours pour cela : il ne vérifie pas si une valeur appartient à une enum.

Une enum définit simplement des symboles pour des valeurs entières. A la différence des #define, ceci ne procède pas par simple remplacement de texte.
L'avantage, non négligeable, d'une enum sur des #define est documentaire en C. Si une variable ou un paramètre est d'un type enum, alors la logique veut que sa valeur soit égale à un des termes de l'énumération. Elle regroupe donc toutes les valeurs possibles que la grandeur est susceptible de prendre (en toute logique). Mais en pratique, rien ne l'impose, et certainement pas le compilateur, il ne s'agit que d'une discipline que le programmeur s'impose.

[gl]

Le compilateur n'est d'aucun secours pour cela : il ne vérifie pas si une valeur appartient à une enum.

Nous somme d'accord que la norme n'impose pas de vérification et que si la valeur ne correspond pas il ne s'agit aucunement d'une erreur.

Toutefois le point sur lequel je me pose une question est : un compilateur donné a-t-il le droit d'émettre un warning dans ce cas de figure ? Je pense que oui (et on rentre dans la qualité de l'implémentation), ce qui peut être une aide intéressante.

[diogene]

n1256 dit :

Annex I
(informative)
Common warnings
...
— A value is given to an object of an enumerated type other than by assignment of an enumeration constant that is a member of that type, or an enumeration object that has the same type, or the value of a function that returns the same enumerated type

qui vérifie si l'utilisation de l'enum est bien cohérente. En fait, il ne s'agit que d'une vérification de type lors d'une assignation, pas que les valeurs obtenues font bien partie de l'énumération (une fonction qui retourne un type enum peut retourner une valeur entière ne faisant pas partie de l'énumération sans warning).

Il me semble difficile qu'il y ait des vérifications plus poussées de la part du compilateur portant cette fois sur les valeurs pour s'assurer qu'une valeur est effectivement égale à une des constantes de l'énumération.

[LittleWhite]

Mince ... pardon pour avoir dit quelque chose de faux. Du coup je suis perplexe sur l'erreur que j'avais eu.

Sinon, dernier avantage de l'enum est dans le switch(). Car le compilateur peut lancer un warning pour dire que nous n'avons pas défini tout les chemins possible de l'enum. ( Bien sur ... un default va enlever le warning, si je me rappelle bien )

[pfeuh]

Salut,

au moment ou j'ai eu besoin de passe E1 | E2 , donc deux valeurs différentes de mon enum ... j'ai du remplacé par le define.

Je trouve ça normal, car si tu veux appliquer des masques logiques, tu as du définir ton enum avec flag0 =1, flag1=2, flag2=4, flag3=8, etc... Alors qu'idéalement, on n'a pas besoin de connaitre les valeurs affectées par le compilateur aux éléments de l'enum. Ce côté "boite noire" est même un de ses intérêts. J'utilise enum pour définir les états d'une machine d'état, les codes d'erreurs, bref, des choses qui découlent d'une liste.

[Bktero]

Certains passages étaient philosophiques ^^

Merci de vos réponses