Attribution de valeurs à un enum

Question

En révisant du vieux code, j'ai remarqué les deux constructions étranges suivantes utilisant des enums (deux fichiers/classes/espaces de noms différents, je les ai juste rassemblés ici) :

enum FirstEnum
   {
    A_CHOICE
   ,ANOTHER_CHOICE=1
   ,YET_SOME_OTHER_CHOICE
   };

enum SecondEnum
   {
    FIRST_CHOICE
   ,SECOND_CHOICE
   ,THIRD_CHOICE
   ,DEFAULT_CHOICE=SECOND_CHOICE
   };

Je pense que les deux constructions sont erronées.

Le premier attribue une valeur à l'un des choix, mais pas aux autres, ce qui signifie que les choses peuvent mal tourner si de nouveaux choix sont ajoutés.

Dans le second cas, nous nous retrouvons avec deux éléments d'énumération ayant la même valeur sous-jacente.

Y a-t-il une raison pour laquelle la norme C++ autorise les deux constructions ?

(en utilisant Visual Studio 2010)

Answer 1

Le premier attribue une valeur à l'un des choix, mais pas aux autres, ce qui signifie que les choses peuvent mal tourner si de nouveaux choix sont ajoutés.

Je ne sais pas ce que vous entendez par "se tromper". Il est bien défini que si vous ne spécifiez pas de valeur pour un énumérateur, sa valeur est une de plus que la précédente (ou zéro, s'il s'agit de la première).

Dans le second cas, nous nous retrouvons avec deux éléments d'énumération ayant la même valeur sous-jacente.

Oui, c'est le cas. Ce serait une erreur si les énumérations étaient censées être un ensemble de unique mais (en C++) elles ne le sont pas.

Y a-t-il une raison pour laquelle la norme C++ autorise les deux constructions ?

En effet, en C++, une énumération est simplement un moyen de déclarer un ensemble de valeurs constantes, nommées et liées entre elles. Elle n'essaie pas de restreindre les valeurs qu'elles peuvent prendre.

Answer 2

Cet article de Microsoft devrait vous aider :

http://msdn.microsoft.com/en-us/library/2dzy4k6e(v=VS.80).aspx

Le premier attribue une valeur à l'un des choix, mais pas aux autres

Par défaut, le premier énumérateur a une valeur de 0, et chaque énumérateur successif est plus grand d'une unité que le précédent, à moins que vous ne spécifiiez explicitement une valeur pour un énumérateur particulier.

Dans le second cas, nous nous retrouvons avec deux éléments d'énumération ayant la même valeur sous-jacente.

Les énumérateurs n'ont pas besoin d'avoir des valeurs uniques au sein d'une énumération. Le nom de chaque énumérateur est traité comme une constante et doit être unique dans la portée où l'énumération est définie.

L'article comprend des exemples de la manière dont ces caractéristiques pourrait être mis à profit.

Answer 3

Je n'ai pas de citation de la norme pour vous, mais les enums sont spécifiés de telle sorte que les valeurs non initialisées prennent une valeur supérieure d'une unité à la valeur qui les précède.

Dans le FirstEnum, YET_SOME_OTHER_CHOICE serait donc 2 (ANOTHER_CHOICE+1). Il est également parfaitement légal d'avoir plusieurs valeurs équivalentes dans une énumération.

Answer 4

Le premier attribue une valeur à l'un des choix, mais pas aux autres, ce qui signifie que les choses peuvent mal tourner si de nouveaux choix sont ajoutés.

Qu'est-ce qui pourrait mal tourner ? Bien sûr, si quelqu'un change le premier exemple en

enum FirstEnum
   {
    A_CHOICE              //0
   ,A_THIRD_CHOICE        //1
   ,ANOTHER_CHOICE=1      //1
   ,YET_SOME_OTHER_CHOICE //2
   };

Alors oui, ils auront des problèmes s'ils ne s'attendaient pas à ce que deux valeurs soient identiques dans l'énumération. Il en va de même si quelqu'un a #define d ces valeurs, et a accidentellement fait en sorte que deux d'entre elles soient identiques.

Et pour votre deuxième exemple, les noms des valeurs de l'énumération donnent une idée de l'utilité de cette méthode. Vous pouvez avoir une valeur par défaut pour les variables de type SecondEnum stockée dans la définition de SecondEnum Vous pouvez ainsi faire des choses telles que

SecondEnum var = DEFAULT_CHOICE;

sans qu'il soit nécessaire de #define ou des constantes qui sont étroitement liées à la définition de l'énumération mais qui n'en font pas partie.

Y a-t-il une raison pour laquelle la norme C++ autorise les deux constructions ?

Je ne fais pas partie du comité de normalisation, mais si je devais deviner, c'est parce que les deux constructions sont utiles aux programmeurs.