Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++.moderated > #1822 > unrolled thread

New strongly type enum proposal featuring inherited enums

Back to article view | Back to comp.lang.c++.moderated

Contents

  New strongly type enum proposal featuring inherited enums Phil Bouchard <philippe@fornux.com> - 2011-08-16 21:28 -0600
    Re: New strongly type enum proposal featuring inherited enums Daniel Krügler <daniel.kruegler@googlemail.com> - 2011-08-18 07:54 -0600
    Re: New strongly type enum proposal featuring inherited enums Pete Becker <pete@versatilecoding.com> - 2011-08-18 07:51 -0600
    Re: New strongly type enum proposal featuring inherited enums Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2011-08-18 07:53 -0600
    Re: New strongly type enum proposal featuring inherited enums Marcel Müller <news.5.maazl@spamgourmet.com> - 2011-08-18 07:52 -0600

#1822 — New strongly type enum proposal featuring inherited enums

Hi,

Is it too late to change the strongly type enum?  I have a proposal
that is much cleaner than what is on its way.

Right now we have:
enum class Val: unsigned long { E1, E2, E3, E4 };

Comments:
1) This design is bad because the ':' sign is reserved for inheritance.

2) Inheriting from another enum would be quite useful.  For example:
enum class Widget {button, combobox, listview};
enum class SuperWidget : Widget {iconview}

This way iconview would be equal to 3, not 0.

3) Redefining the underlying type could be easily done with:
enum class Val { unsigned long E1, E2, E3, E4 };

This is much more neat and is similar to a declaration of multiple instances:
const unsigned long E1, E2, E3, E4;


Thanks,
-Phil


--
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

[toc] | [next] | [standalone]

#1830

On 2011-08-17 05:28, Phil Bouchard wrote:
>
> Hi,
>
> Is it too late to change the strongly type enum?

Yes, the ISO standard C++11 is accepted.

> I have a proposal
> that is much cleaner than what is on its way.
>
> Right now we have:
> enum class Val: unsigned long { E1, E2, E3, E4 };
>
> Comments:
> 1) This design is bad because the ':' sign is reserved for inheritance.

I disagree. First, ':' is only "reserved" for inheritance for class
types, second, even, if we look at it similar to class types I don't
consider the current state as incorrect, because we can (conceptually)
consider an enum to "derive from" an underlying type.

> 2) Inheriting from another enum would be quite useful. For example:
> enum class Widget {button, combobox, listview};
> enum class SuperWidget : Widget {iconview}

The current state would not disallow such an extension in the future,
so what is the problem?

> This way iconview would be equal to 3, not 0.

Maybe, that would depend on an actual proposal that describes the
semantics in this way.

> 3) Redefining the underlying type could be easily done with:
> enum class Val { unsigned long E1, E2, E3, E4 };
>
> This is much more neat and is similar to a declaration of multiple
> instances:
> const unsigned long E1, E2, E3, E4;

I don't consider this alternative as superior as the current state. To
me it looks, as if Ei (i=1-4) are data members of Val. It would imply
to me that I could write

enum class Val { unsigned long E1; unsigned long E2; unsigned long E3,
unsigned long E4; };

Does that mean that we could also use different underlying types for
individual enumerator values?

HTH & Greetings from Bremen,

- Daniel Krügler


--
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

[toc] | [prev] | [next] | [standalone]

#1831

On 2011-08-16 21:28:17 +0000, Phil Bouchard said:

> Hi,
>
> Is it too late to change the strongly type enum?

Yes, C++11 has been unanimously approved. It will be an official
standard in a few weeks.

No, work is just starting on the next version of the C++ standard.

>  I have a proposal
> that is much cleaner than what is on its way.
>
> Right now we have:
> enum class Val: unsigned long { E1, E2, E3, E4 };
>
> Comments:
> 1) This design is bad because the ':' sign is reserved for inheritance.

Really? Where does the standard say that it's "reserved"? <g>

It's currently used to indicate inheritance, to separate two
expressions in a ternary operator, and to mark the size of a bitfield.

>
> 2) Inheriting from another enum would be quite useful.  For example:
> enum class Widget {button, combobox, listview};
> enum class SuperWidget : Widget {iconview}
>
> This way iconview would be equal to 3, not 0.

Sure. That's not precluded by using ':' to indicate that an enum is
based on an integral type.

--
 Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)


[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

[toc] | [prev] | [next] | [standalone]

#1832

Phil Bouchard <philippe@fornux.com> writes:

> Is it too late to change the strongly type enum?  I have a proposal
> that is much cleaner than what is on its way.

Too late.

> Right now we have:
> enum class Val: unsigned long { E1, E2, E3, E4 };
>
> Comments:
> 1) This design is bad because the ':' sign is reserved for inheritance.

It makes perfect sense to me. Sub-classing is restriction. You define
Val as a restriction of unsigned long to four possible values (and you
give symbolic names to these values to make sure you do not violate the
restriction). A Val "is a" unsigned long.

> 2) Inheriting from another enum would be quite useful.  For example:
> enum class Widget {button, combobox, listview};
> enum class SuperWidget : Widget {iconview}

This contradicts with the meaning of sub-typing, which is restriction,
and which you use here as augmentation. Assigning a value of type
SuperWidget to a variable of type Widget would be forbidden, if I
understand your example correctly. The exact opposite of what happens
between a sub-class and its base-class.

> 3) Redefining the underlying type could be easily done with:
> enum class Val { unsigned long E1, E2, E3, E4 };
>
> This is much more neat and is similar to a declaration of multiple instances:
> const unsigned long E1, E2, E3, E4;

In my opinion, this looks much like a list of members. I know, unions do
this already, but there's "class" in the type declaration here.

-- Alain.


--
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

[toc] | [prev] | [next] | [standalone]

#1833

Phil Bouchard wrote:
>
> Right now we have:
> enum class Val: unsigned long { E1, E2, E3, E4 };
>
> Comments:
> 1) This design is bad because the ':' sign is reserved for inheritance.

I see no problem so far.

> 2) Inheriting from another enum would be quite useful.  For example:
> enum class Widget {button, combobox, listview};
> enum class SuperWidget : Widget {iconview}
>
> This way iconview would be equal to 3, not 0.

I had the same idea some time ago. However, poeple told me that it is
not that easy.

First of all inheriting from a type implies that slicing is possible.
But SuperWidget can't ever be safely converted to Widget, becuse
Widget can't take the value iconview. In fact it is the other way
around. Widget is Safely a SuperWidget. The covariance/contravariance
is swapped.


> 3) Redefining the underlying type could be easily done with:
> enum class Val { unsigned long E1, E2, E3, E4 };

This implies that the type is specific to each enum constant. It isn't. IMO

 enum class Val: unsigned long

is fine. Val is an unsigned long, but it cannot be implicitly
converted because it is a private base.


Marcel


--
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c++.moderated

csiph-web