C++ – Underlying Type of Weak Typed Enum in C++11

c++c++11

C++11 introduced strongly typed enums, with the syntax enum class. These are not compatible with integer types and require explicit casts to obtain their numeric value. C++11 also introduces the ability to specify the storage class for weakly typed enums with the form enum name : type {}. This is fine up to here.

But it looks like even if an weakly typed enum has a given storage class, the type of its items is still int. I tried with Visual Studio 2012, November CTP release. Consider the following code:

enum charEnum : char { A = 'A' };
enum longEnum : long long { Tera = 1000000000000 };

void fct(char val) {}
void fct(int val) {}
void fct(long long val) {}

int main() 
{
    static_assert(sizeof(A) == sizeof(char), "check charEnum size");
    static_assert(sizeof(Tera) == sizeof(long long), "check longEnum size");
    fct('A');  // calls fct(char)
    fct(1);    // calls fct(int)
    fct(2ll);  // calls fct(long long)
    fct(A);    // calls fct(int) !
    fct(Tera); // calls fct(int), with truncation !
    fct((long long)Tera);  // calls fct(long long)
    return 0;
}

The overloaded function called for an enumeration value is always fct(int), even if this results in a truncation of the value. Of course, with an explicit cast, we can call the overloaded function, but this was also possible in traditional C++03 syntax.

Am I missing something obvious? Why is that? Is there a better workaround than an explicit cast?

Best Answer

It's a compiler bug. According to §7.2/9 and §4.5/4:

§7.2/9:
The value of an enumerator or an object of an unscoped enumeration type is converted to an integer by integral promotion (4.5)

§4.5/4:
A prvalue of an unscoped enumeration type whose underlying type is ﬁxed (7.2) can be converted to a prvalue of its underlying type. Moreover, if integral promotion can be applied to its underlying type, a prvalue of an unscoped enumeration type whose underlying type is ﬁxed can also be converted to a prvalue of the promoted underlying type.

The last one should convert to long long, not int. The char case is a point of contention. (!)

Test program:

#include <iostream>

enum charEnum : char      { A = 'A' };
enum longEnum : long long { Tera = 1000000000000 };

void fct(char val)      { std::cout << "fct(char)"      << std::endl; }
void fct(int val)       { std::cout << "fct(int)"       << std::endl; }
void fct(long long val) { std::cout << "fct(long long)" << std::endl; }

int main() 
{
    static_assert(sizeof(A)    == sizeof(char),      "check charEnum size");
    static_assert(sizeof(Tera) == sizeof(long long), "check longEnum size");

    fct('A');
    fct(1);
    fct(2ll);
    fct(A);
    fct(Tera);
    fct((long long)Tera);
}

MSVC2012NovCTP output:

fct(char)
fct(int)
fct(long long)
fct(int)
fct(int)
fct(long long)

g++ 4.7.1:

fct(char)
fct(int)
fct(long long)
fct(int)
fct(long long)
fct(long long)

Related Solutions

C++ – Underlying Type of an Enum in C++11

enum class is a C++0x feature, it is not present in C++03.

In standard C++, enumerations are not type-safe. They are effectively integers, even when the enumeration types are distinct. This allows the comparison between two enum values of different enumeration types. The only safety that C++03 provides is that an integer or a value of one enum type does not convert implicitly to another enum type. Additionally, the underlying integral type, the size of the integer, cannot be explicitly specified; it is implementation defined. Lastly, enumeration values are scoped to the enclosing scope. Thus, it is not possible for two separate enumerations to have matching member names. C++0x will allow a special classification of enumeration that has none of these issues. This is expressed using the enum class declaration

Examples (from the wikipedia article):

enum Enum1;                   //Illegal in C++ and C++0x; no size is explicitly specified.
enum Enum2 : unsigned int;    //Legal in C++0x.
enum class Enum3;             //Legal in C++0x, because enum class declarations have a default type of "int".
enum class Enum4: unsigned int; //Legal C++0x.
enum Enum2 : unsigned short;  //Illegal in C++0x, because Enum2 was previously declared with a different type.

As for the serialization part (which I think was not part of the original question), I prefer to create a helper class that translates enum items into their string equivalent (and back), as the names are usually more stable than the integer values they represent, as enum items can be (and sometimes are) reordered without changing the code behavior.

C++ – Enum vs Strongly Typed Enum

OK, first example: old-style enums do not have their own scope:

enum Animals {Bear, Cat, Chicken};
enum Birds {Eagle, Duck, Chicken}; // error! Chicken has already been declared!

enum class Fruits { Apple, Pear, Orange };
enum class Colours { Blue, White, Orange }; // no problem!

Second, they implicitly convert to integral types, which can lead to strange behaviour:

bool b = Bear && Duck; // what?

Finally, you can specify the underlying integral type of C++11 enums:

enum class Foo : char { A, B, C};

Previously, the underlying type was not specified, which could cause compatibility problems between platforms. Edit It has been pointed out in comments that you can also specify the underlying integral type of an "old style" enum in C++11.

Best Answer

Related Solutions

C++ – Underlying Type of an Enum in C++11

C++ – Enum vs Strongly Typed Enum

Related Question