将值分配给枚举

Question

While doing a review of some older code, I notice the following two strange constructions using enum (two different files/classes/namespaces, just putting them together here):

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

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

I think both constructions are wrong.

The first one assigns a value to one of the choices, but not to the others, meaning that things might go wrong if new choices are added.

In the second case, we end up with two enumeration elements having the same underlying value.

Is there any reason why the C++ standard allows both constructions?

(using Visual Studio 2010)

Answer 1

The first one assigns a value to one of the choices, but not to the others, meaning that things might go wrong if new choices are added.

I don't know what you mean by "go wrong". It's well-defined that if you don't specify a value for an enumerator, its value is one more than the previous (or zero, if it's the first).

In the second case, we end up with two enumeration elements having the same underlying value.

Yes we do. That would be wrong if enumerations were supposed to be a set of unique values but (in C++) they aren't.

Is there any reason why the C++ standard allows both constructions?

Because, in C++, an enumeration is simply a way to declare a set of related, named, constant values. It doesn't try to restrict what values they can take.

Answer 2

This article from Microsoft should help:

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

The first one assigns a value to one of the choices, but not to the others

By default, the first enumerator has a value of 0, and each successive enumerator is one larger than the value of the previous one, unless you explicitly specify a value for a particular enumerator.

In the second case, we end up with two enumeration elements having the same underlying value.

Enumerators needn't have unique values within an enumeration. The name of each enumerator is treated as a constant and must be unique within the scope where the enum is defined.

The article includes examples of how these features could be taken advantage of.

Answer 3

I don't have a quote from the standard for you, but enums are specified such that uninitialized values take on a value one larger than the value preceding them.

In the FirstEnum, YET_SOME_OTHER_CHOICE would therefore be 2 (ANOTHER_CHOICE+1). It is also perfectly legal to have multiple equivalent values within an enum.

Answer 4

The first one assigns a value to one of the choices, but not to the others, meaning that things might go wrong if new choices are added.

What might go wrong? Sure, if somebody changes the first example to

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

Then yes, they will get problems if they didn't expect two values to be the same in the enum. The same if somebody had #define d these values, and accidentally made two of them the same.

And for your second example, the names of the values in the enumeration give a hint as to why that is useful. You can have a default value for variables of type SecondEnum stored in the definition of SecondEnum , allowing you to do things like

SecondEnum var = DEFAULT_CHOICE;

without the need for #define s or constants that are closely coupled to the enum definition but aren't part of it.

Is there any reason why the C++ standard allows both constructions?

I'm not on the standards committee, but if I were to guess, it's because both constructions are useful for programmers.