First, I want to say, according to cppreference.com, it is somewhat impossible to value-initialize an enum.
According to http://en.cppreference.com/w/cpp/language/value_initialization, value-initializing an enum actually performs zero-initialization. It then follows that, according to http://en.cppreference.com/w/cpp/language/zero_initialization, the effect of zero-initializing an enum is:
If T is a scalar type, the object's initial value is the integral constant zero implicitly converted to T.
However, an integral constant zero is not implicitly convertible to an enum. Ultimately, an enum cannot be value-initialized. This sounds weird, and value-initializing an enum does work on VC, GCC, and clang. So, what does the standard say about this?
Second, according to http://en.cppreference.com/w/cpp/language/static_cast:
Integer, floating-point, or enumeration type can be converted to any complete enumeration type (the result is unspecified (until C++17) undefined behavior (since C++17) if the value of expression, converted to the enumeration's underlying type, is not one of the target enumeration values)
So, does this imply that value-initializing an enum (if it works at all) may actually lead to undefined behavior if the target enum does not have an enumerator equal to 0?
The answer to this was given in the comments. My attempt of explaining the entire standardese behind it is given below.
To zero-initialize an object or reference of type T means:
- if
T is a scalar type (3.9), the object is initialized to the value
obtained by converting the integer literal 0 (zero) to T;
(Enumerations are scalar types; §3.9/9)
So as the conversion is not said to be implicit, we're not looking in §4, but §5.2.9;
The result of the expression static_cast<T>(v) is the result of
converting the expression v to type T.
§5.2.9/10 then defines how integral values are converted to enumeration types.
A value of integral or enumeration type can be explicitly converted to
an enumeration type. The value is unchanged if the original value is
within the range of the enumeration values (7.2). Otherwise, the resulting
value is unspecified (and might not be in that range).
It must be shown that zero is in the range of enumeration values for all enumerations.
The next five quotes are taken from §7.2/8:
For an enumeration whose underlying type is fixed, the values of the
enumeration are the values of the underlying type.
Since all permitted underlying types include zero in their range of values*, this automatically gives the desired result. Now, for enumerations without fixed underlying types,
Otherwise, for an enumeration where emin is the smallest
enumerator and e max is the largest, the values of the
enumeration are the values in the range b min to b
max , defined as follows:
I.e. we have to show that bmin is always less than or equal to zero, and bmax is always greater or equal to zero.
Let K be 1 for a two’s
complement representation and 0 for a one’s complement or
sign-magnitude representation.
b max is the smallest value greater than or equal to max(|e min| − K, |e max|) and equal to 2M − 1, where
M is a non-negative integer.
|e max| is non-negative, and the maximum of two numbers is at least as large as both numbers are. Hence max(|e min| − K, |e max|) is non-negative as well, and bmax must be greater or equal to that number - so our first requirement is met.
b min is zero if emin is non-negative and −(bmax + K) otherwise.
bmin is clearly either zero or negative: bmax is non-negative as shown above, and K is non-negative (0 or 1), hence the additive inverse of their sum is non-positive. Our second requirement is met. Finally,
If the enumerator-list is empty, the values of the
enumeration are as if the enumeration had a single enumerator with
value 0.
This leads to the above result by setting emin = emax = 0.
- This reduces to the claim "All integral types have zero in their range of values", which is left to prove for the reader.
1: This can be undestood like so:
enum class SomeEnum : int { V1 = 0, V2 = 1, V3 = 2 };
SomeEnum a = 0; // compile error
SomeEnum b = SomeEnum.V1; // OK
This is basic protection from undefined behavior!
2: Yes and Yes :)
SomeEnum c = static_cast<SomeEnum>(1); // = SomeEnum.V2
SomeEnum d = static_cast<SomeEnum>(5); // undefined behavior
static_cast is dangerous by definition, it shoud only be used to support serrialization or old c interfaces!
