TITLE: How many enum values does it take to ... (part 2)


PROBLEM: 

How many allowable values are there for an enum such as this

enum Fruit {orange, apple, grape};


RESPONSE: John Max Skaller <maxtal@physics.su.OZ.AU>

[...] There are 4.  No, I'm not
kidding, these are the new C++ rules.  The range of values of an
enum is the same as the smallest bit field that can hold it, the
underlying type is unsigned unless one of the specified
enumerators is negative.


RESPONSE: cbarber@bbn.com (Christopher Barber)

No, you are wrong.  The language may allow 4 values, but that does not mean
that there are four valid values from a programmer's standpoint!  There are
still only three fruit above.  Besides, if we used your logic than how many
fruit would there be if we wrote this?

   enum Fruit { orange, apple, grape=129 };


RESPONSE: clamage@taumet.Eng.Sun.COM (Steve Clamage)

No, YOU are wrong. The C++ Committee has adopted the rule as Skaller stated.
In your example, 8 bits are required to hold all the values, and 256
enumeration values are possible. It is not possible to discover how
many have been given names in the source code, short of providing a hand-
written constant -- but that has always been true for examples like this.

The reason for the change was two-fold:

1. It allows you to OR two enum values and ensure the result can be stored
in a variable of that enum type:
	Fruit temp = Fruit(apple | grape);	// this will now work
Previously, the result might not correspond to a value in the min-to-max
range of the enum. Suppose, for example, that apple had the value 64 instead
of 1 -- the result would be 193, outside the former range. Now the range
extends to 255, so the expression is OK.

2. It allows you to fill in deliberate gaps in an enumeration and be sure
that the result will fit in a variable of the type. Example:

    enum error_type { warning=0, soft_error=1000, error=2000, fatal=3000 };
    const error_type low_on_memory = (error_type)(warning+97);
    const error_type mem_parity_check = (error_type)(fatal+2);

The result of this code is undefined (or unspecified at best) under the
earlier rules. The results are well-defined under the new rules.

I've only shown the non-negative cases here, but it also works for negative
enumerators.

I don't believe the new rules result in any less functionality than the old,
contrary to your claim above.