"enum" vs. "enum class"

Discussion in 'C++' started by Ansel, Aug 26, 2012.

  1. Ansel

    Ansel Guest

    Are there additional semantics when using "enum class" than when using
    "enum" in C++ 11, or are they exactly the same?
    Ansel, Aug 26, 2012
    #1
    1. Advertising

  2. Ansel

    Bo Persson Guest

    Bo Persson, Aug 26, 2012
    #2
    1. Advertising

  3. Ansel

    Ansel Guest

    Bo Persson wrote:
    > 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
    >
    >


    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?
    Ansel, Aug 27, 2012
    #3
  4. Ansel

    Öö Tiib Guest

    On Monday, August 27, 2012 6:10:41 AM UTC+3, Ansel wrote:
    > Bo Persson wrote:
    > > 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

    >
    > 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.
    Öö Tiib, Aug 27, 2012
    #4
  5. Ansel

    Ansel Guest

    Öö Tiib wrote:
    > On Monday, August 27, 2012 6:10:41 AM UTC+3, Ansel wrote:
    >> Bo Persson wrote:
    >>> 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

    >>
    >> 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.


    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.
    Ansel, Aug 27, 2012
    #5
  6. Ansel <> wrote:
    > "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.
    Juha Nieminen, Aug 27, 2012
    #6
  7. Ansel

    Ansel Guest

    Juha Nieminen wrote:
    > Ansel <> wrote:
    >> "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.


    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.
    Ansel, Aug 27, 2012
    #7
  8. Ansel

    Öö Tiib Guest

    On Monday, August 27, 2012 9:11:09 AM UTC+3, Ansel wrote:
    > Juha Nieminen wrote:
    > > Ansel <> wrote:
    > >> "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.

    >
    > 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.
    Öö Tiib, Aug 27, 2012
    #8
  9. Ansel

    Ansel Guest

    Öö Tiib wrote:
    > On Monday, August 27, 2012 9:11:09 AM UTC+3, Ansel wrote:
    >> Juha Nieminen wrote:
    >>> Ansel <> wrote:
    >>>> "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.

    >>
    >> 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.


    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?

    >
    > 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, Aug 27, 2012
    #9
  10. Ansel

    Öö Tiib Guest

    On Monday, August 27, 2012 9:48:18 AM UTC+3, Ansel wrote:
    > �� Tiib wrote:
    > > 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.


    OK.

    > > 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?


    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.
    Öö Tiib, Aug 27, 2012
    #10
  11. Ansel

    Ike Naar Guest

    On 2012-08-27, Ansel <> wrote:
    > 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
    Ike Naar, Aug 27, 2012
    #11
  12. Ansel

    Ansel Guest

    Öö Tiib wrote:
    > On Monday, August 27, 2012 9:48:18 AM UTC+3, Ansel wrote:
    >> ?? Tiib wrote:
    >>> 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.

    >
    > OK.
    >
    >>> 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?

    >
    > 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).

    >> 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,


    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).

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

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


    Was the in-between one really necessary?

    > The
    > compilers may warn about others if they want to but have to convert.
    Ansel, Aug 27, 2012
    #12
  13. Ansel

    Ansel Guest

    Ike Naar wrote:
    > On 2012-08-27, Ansel <> wrote:
    >> 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.


    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
    Ansel, Aug 27, 2012
    #13
  14. Ansel

    Ike Naar Guest

    On 2012-08-27, Ansel <> wrote:
    > Ike Naar wrote:
    >> On 2012-08-27, Ansel <> wrote:
    >>> 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.

    >
    > 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


    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.
    Ike Naar, Aug 27, 2012
    #14
  15. Ansel

    Ansel Guest

    Ike Naar wrote:
    > On 2012-08-27, Ansel <> wrote:
    >> Ike Naar wrote:
    >>> On 2012-08-27, Ansel <> wrote:
    >>>> 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.

    >>
    >> 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

    >
    > 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.
    Ansel, Aug 27, 2012
    #15
  16. Ansel

    Ike Naar Guest

    On 2012-08-27, Ansel <> wrote:
    > Ike Naar wrote:
    >>>>
    >>>> http://www.stroustrup.com/C 11FAQ.html#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.


    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.
    Ike Naar, Aug 27, 2012
    #16
  17. Ansel

    Ansel Guest

    Ike Naar wrote:
    > On 2012-08-27, Ansel <> wrote:
    >> Ike Naar wrote:
    >>>>>
    >>>>> http://www.stroustrup.com/C 11FAQ.html#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.

    >
    > 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
    >
    > ).
    >
    >> Feel free to enter my table into the FAQ.

    >
    > 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.
    Ansel, Aug 27, 2012
    #17
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. -

    enum within an enum

    -, Jun 12, 2005, in forum: Java
    Replies:
    6
    Views:
    525
  2. Jerminia
    Replies:
    3
    Views:
    615
    Roedy Green
    Oct 7, 2005
  3. Ernst Murnleitner

    How to enum an enum?

    Ernst Murnleitner, Nov 12, 2003, in forum: C++
    Replies:
    5
    Views:
    445
    Rolf Magnus
    Nov 13, 2003
  4. mrhicks
    Replies:
    2
    Views:
    406
    Dave Thompson
    Jun 10, 2004
  5. Brian
    Replies:
    4
    Views:
    2,589
    Brian
    Feb 27, 2010
Loading...

Share This Page