"enum" vs. "enum class"

[Ansel]

Are there additional semantics when using "enum class" than when using
"enum" in C++ 11, or are they exactly the same?

 

[Bo Persson]

Ansel skrev 2012-08-26 13:31:

Are there additional semantics when using "enum class" than when using
"enum" in C++ 11, or are they exactly the same?

Yes, lots. Why else would someone introduce a new construct?

http://en.wikipedia.org/wiki/C++11#Strongly_typed_enumerations


Bo Persson

 

[Ansel]

Ansel skrev 2012-08-26 13:31:

Yes, lots. Why else would someone introduce a new construct?

http://en.wikipedia.org/wiki/C++11#Strongly_typed_enumerations

I wasn't asking about the new construct though, but rather if the old one
works just like the new one now. IOW, is the word "class" unnecessary?

 

[Öö Tiib]

I wasn't asking about the new construct though, but rather if the old one
works just like the new one now. IOW, is the word "class" unnecessary?

Old syntax works the way it did.

New standards always avoid breaking behavior of legacy code unless it is impossible. It was impossible with 'auto' keyword (but no one used in old sense anyway). 'enum' is used in a lot of code so that they do not dare to modify it ever.

 

[Ansel]

Old syntax works the way it did.

New standards always avoid breaking behavior of legacy code unless it
is impossible. It was impossible with 'auto' keyword (but no one used
in old sense anyway). 'enum' is used in a lot of code so that they do
not dare to modify it ever.

From
http://www.codeguru.com/cpp/cpp/article.php/c19083/C-2011-Stronglytyped-Enums.htm:

"However, it is possible to specify the underlying type for traditional
enums too. This is also legal in C++ 2011 (and actually supported for some
years by various compilers):

enum Selection : unsigned char
{
None,
Single,
Multiple,
};

Forward declaration with traditional enums will also be possible"

Comment (anyone) on the above please.

 

[Juha Nieminen]

"However, it is possible to specify the underlying type for traditional
enums too. This is also legal in C++ 2011 (and actually supported for some
years by various compilers):

enum Selection : unsigned char
{
None,
Single,
Multiple,
};

Forward declaration with traditional enums will also be possible"

Comment (anyone) on the above please.

I don't understand what you are asking.

 

[Ansel]

I don't understand what you are asking.

Did you read the thread from the beginning? (It's all in the post you
replied to). From what you snipped above, it appears you didn't, for that is
just what I copied from another website. In my last post, I wrote, "Comment
(anyone) on the above please.", meaning in the context of the whole thread.
Oo Tiib said: "New standards always avoid breaking behavior of legacy code
unless it is impossible.". So is the website article wrong in saying that
enums without the 'class' keyword can have the base type specified, and
such? It all goes back to what I asked in my OP.

 

[Öö Tiib]

Did you read the thread from the beginning? (It's all in the post you
replied to). From what you snipped above, it appears you didn't, for that is
just what I copied from another website. In my last post, I wrote, "Comment
(anyone) on the above please.", meaning in the context of the whole thread.
Oo Tiib said: "New standards always avoid breaking behavior of legacy code
unless it is impossible.". So is the website article wrong in saying that
enums without the 'class' keyword can have the base type specified, and
such? It all goes back to what I asked in my OP.

Such forward declaration is allowed:
enum Selection : unsigned char;

The article calls it "traditional" but actually it is new syntax. Such enum works like old enum but underlying type is user-specified.

Such forward declaration is not allowed:
enum Selection;

It was not allowed before.

Even if the new standard allowed both forward declarations (or some compiler allows it as extension) it would not break any existing code. That's why it is hard to understand what you ask.

 

[Ansel]

Such forward declaration is allowed:
enum Selection : unsigned char;

The article calls it "traditional" but actually it is new syntax.

The "traditional" part is referring to the use of 'enum' instead of 'enum
class'. 'enum' is the traditional construct wordage while 'enum class' is
the C++ 11 construct wordage.

Such enum works like old enum but underlying type is user-specified.

So then, it *doesn't* work like the old enum. Do you see my original
question now? Maybe they should have left the old enum alone (?). The old
enum is gone in C++ 11 and now there are 2 new enum constructs. So then, the
*new* "old style" enum implicitly converts to int?

 

[Öö Tiib]

The "traditional" part is referring to the use of 'enum' instead of 'enum
class'. 'enum' is the traditional construct wordage while 'enum class' is
the C++ 11 construct wordage.
OK.


So then, it *doesn't* work like the old enum. Do you see my original
question now?

No. The old enum had implementation-specified underlying type. So it was
(at some cases aggravatingly) dim for developer. The code that did manage
to work with old enum still works.

Maybe they should have left the old enum alone (?). The old
enum is gone in C++ 11 and now there are 2 new enum constructs.

Nothing is gone. Why you say it? There are now 3 enums, the one
exactly as in C++2003, the "traditional" with underlying type
specified and the totally new 'class enum'.

So then, the *new* "old style" enum implicitly converts to int?

Yes. The 'class enum' alone is not converting implicitly. The compilers
may warn about others if they want to but have to convert.

 

[Ike Naar]

So then, it *doesn't* work like the old enum. Do you see my original
question now? Maybe they should have left the old enum alone (?). The old
enum is gone in C++ 11 and now there are 2 new enum constructs. So then, the
*new* "old style" enum implicitly converts to int?

The old enum isn't gone.
Below is a short description of the new enums in C++ 2011.

http://www.stroustrup.com/C++11FAQ.html#enum

 

[Ansel]

No. The old enum had implementation-specified underlying type. So it
was (at some cases aggravatingly) dim for developer. The code that
did manage to work with old enum still works.

OK. (I knew that).

Nothing is gone. Why you say it? There are now 3 enums,

Ah yes! So there are! I stand corrected.

the one
exactly as in C++2003, the "traditional" with underlying type
specified and the totally new 'class enum'.

A sad state of affairs for those learning to program and using C++ do learn
with. One example, then, of C++ not being good for that. (That was an aside,
but noteworthy I think).

Yes. The 'class enum' alone is not converting implicitly.

Was the in-between one really necessary?

 

[Ansel]

The old enum isn't gone.

Oo Tiib mostly cleared it up on his last post.

Below is a short description of the new enums in C++ 2011.

http://www.stroustrup.com/C++11FAQ.html#enum

A table is appropriate:

Feature enum 2003 ('enum') enum Bastard ('enum :') enum 2011
('enum class :')

Can specify underlying type? N Y Y
Prevents implicit conversion to 'int'? N N Y
Prevents export of enumerators? N N Y

 

[Ike Naar]

Oo Tiib mostly cleared it up on his last post.


A table is appropriate:

Feature enum 2003 ('enum') enum Bastard ('enum :') enum 2011
('enum class :')

Can specify underlying type? N Y Y
Prevents implicit conversion to 'int'? N N Y
Prevents export of enumerators? N N Y

Have you read the FAQ? If not, please do, it may clear up
some misunderstanding.
There is nu such thing as enum Bastard.
There are enum and enum class,
both can optionally have the underlying type specified.
That makes four combinations:

enum Color {red, green};
enum Color : unsigned char {red, green};
enum class Color {red, green};
enum class Color : unsigned char {red, green};

The first one is the old-style enum.

 

[Ansel]

Have you read the FAQ? If not, please do, it may clear up
some misunderstanding.
There is nu such thing as enum Bastard.
There are enum and enum class,
both can optionally have the underlying type specified.
That makes four combinations:

enum Color {red, green};
enum Color : unsigned char {red, green};
enum class Color {red, green};
enum class Color : unsigned char {red, green};

The first one is the old-style enum.

I think my table sums it up quite nicely against the key operational
criteria, and there are really only 3 distinct constructs (the underlying
type being an option in enum 2012, and what defines enum Bastard), not 4.
Feel free to enter my table into the FAQ.

 

[Ike Naar]

I think my table sums it up quite nicely against the key operational
criteria, and there are really only 3 distinct constructs (the underlying
type being an option in enum 2012, and what defines enum Bastard), not 4.

So for "enum class" (and "enum struct") you consider the underlying
type specification to be an option, while for "enum" you're
considering it to be a distinct construct? It's your choice, of course,
but it goes against the syntax for enums in C++2011 (section 7.2),
which treats the underlying type specification in the same
way for "enum" / "enum class" / "enum struct".

(For a draft version of C++2011, see

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3242.pdf

).

Feel free to enter my table into the FAQ.

You'd have to ask Bjarne Stroustrup. It's his FAQ.

 

[Ansel]

So for "enum class" (and "enum struct") you consider the underlying
type specification to be an option, while for "enum" you're
considering it to be a distinct construct?

It's fuzzy, because you can't have C++ 03 without have an
underlying-type-optionless enum.

It's your choice, of
course, but it goes against the syntax for enums in C++2011 (section
7.2),

But the perspective given (the context) was across C++ versions.

which treats the underlying type specification in the same
way for "enum" / "enum class" / "enum struct".

(For a draft version of C++2011, see

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3242.pdf

).


You'd have to ask Bjarne Stroustrup. It's his FAQ.

Ask? I was offering. Bjarne, feel free to use "my" enum table in your FAQ.