When we have,
struct E { enum E_ { HELLO }; }; // \'E\' is inheritable
then why do we need,
enum class E { HELLO }; // \'E
Do we really need “enum class” in C++0x?
No, we don't "need" enum class
. We can get sufficiently equivalent functionality in other ways. But by that logic, we don't "need" a lot of stuff in C++. We don't "need" virtual functions and inheritance, since we can just implement it manually with vtables and such. We don't "need" member functions; these can be emulated by having them take an additional argument.
Language features exist to make programmers lives easier. Just because something can be done manually doesn't mean that it should.
enum class
has the following properties:
enum class
, but that's true for most new features. Once you get used to it, it's fine.enum class
definitions. Without this macro, you have to spend quite a bit of effort getting all of the corner cases to work. And even so, someone had to write and debug that macro.So no, we do not "need" them. But they're still a great addition to the language.
In the first case, the type of HELLO
is not E
, whereas in the second case, the type of HELLO
is E
.
For a good demonstration of why this is important, see Howard Hinnant's answer to "“enum class” emulation or solid alternative for MSVC 10.0."
enum class
and enum struct
are "semantically equivalent" (i.e., the same), per C++0x FDIS §7.2/2.
I think you need to read in the other advantages of these new enums
http://www.stroustrup.com/C++11FAQ.html#enum
Besides what was already mentioned, an advantage of enum class
is better type safety - the enum class
enumerators don't convert implicitly to integers.
Yes, we do. Looks like no one pointed out this before. What about if you need to set size of an enum
and keep still according to C++ standard? enum class
can do. And with type safety as already mentioned. It's reduce so much possible bugs in code and the mess to mixing int
and enum
s. They wasn't never the same thing for me. Amazing. e.g., enum class foo : int16_t { ... }
I'm sure each member is an int16_t
and not up to implementation decide what's "better" for me.
EDIT:
Also, we can have duplicated values (not names) in the list. Which make a lot of sense depending to context.