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

Groups > comp.lang.c++ > #8967 > unrolled thread

New strongly type enum proposal featuring inherited enums

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

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 Victor Bazarov <v.bazarov@comcast.invalid> - 2011-08-17 08:16 -0400
      Re: New strongly type enum proposal featuring inherited enums Phil Bouchard <philippe@fornux.com> - 2011-08-17 14:25 -0400
        Re: New strongly type enum proposal featuring inherited enums "Bo Persson" <bop@gmb.dk> - 2011-08-18 14:32 +0200
      Re: New strongly type enum proposal featuring inherited enums Fred <fred.l.kleinschmidt@boeing.com> - 2011-08-17 11:31 -0700
        Re: New strongly type enum proposal featuring inherited enums "Bo Persson" <bop@gmb.dk> - 2011-08-18 14:30 +0200
      Re: New strongly type enum proposal featuring inherited enums Phil Bouchard <philippe@fornux.com> - 2011-08-17 18:01 -0400
        Re: New strongly type enum proposal featuring inherited enums Marc <marc.glisse@gmail.com> - 2011-08-17 23:16 +0000
          Re: New strongly type enum proposal featuring inherited enums Marc <marc.glisse@gmail.com> - 2011-08-17 23:19 +0000
          Re: New strongly type enum proposal featuring inherited enums Phil Bouchard <philippe@fornux.com> - 2011-08-18 00:07 -0400
    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

#8967 — 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]

#8979

On 8/16/2011 11:28 PM, Phil Bouchard wrote:
> Is it too late to change the strongly type enum?[..]

We have a new Standard (ISO/IEC 14882:2011) as of August 12th, so it's 
late for that one, but there is always the next Standard.

V
-- 
I do not respond to top-posted replies, please don't ask

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

#9007

On 8/17/2011 8:16 AM, Victor Bazarov wrote:
> On 8/16/2011 11:28 PM, Phil Bouchard wrote:
>> Is it too late to change the strongly type enum?[..]
>
> We have a new Standard (ISO/IEC 14882:2011) as of August 12th, so it's
> late for that one, but there is always the next Standard.
>
> V

Dam, I'm one week late.


-Phil

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

#9040

Phil Bouchard wrote:
> On 8/17/2011 8:16 AM, Victor Bazarov wrote:
>> On 8/16/2011 11:28 PM, Phil Bouchard wrote:
>>> Is it too late to change the strongly type enum?[..]
>>
>> We have a new Standard (ISO/IEC 14882:2011) as of August 12th, so
>> it's late for that one, but there is always the next Standard.
>>
>> V
>
> Dam, I'm one week late.
>
>

You are in reality more than a year too late.

The standard has been in "beta" for a long time, and no new proposals 
has been accepted.


Bo Persson

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

#9008

On Aug 17, 5:16 am, Victor Bazarov <v.baza...@comcast.invalid> wrote:
> On 8/16/2011 11:28 PM, Phil Bouchard wrote:
>
> > Is it too late to change the strongly type enum?[..]
>
> We have a new Standard (ISO/IEC 14882:2011) as of August 12th, so it's
> late for that one, but there is always the next Standard.
>
> V
> --
> I do not respond to top-posted replies, please don't ask

Why wasn't it designed using a style similar to templates:

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

--
Fred K

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

#9039

Fred wrote:
> On Aug 17, 5:16 am, Victor Bazarov <v.baza...@comcast.invalid>
> wrote:
>> On 8/16/2011 11:28 PM, Phil Bouchard wrote:
>>
>>> Is it too late to change the strongly type enum?[..]
>>
>> We have a new Standard (ISO/IEC 14882:2011) as of August 12th, so
>> it's late for that one, but there is always the next Standard.
>>
>> V
>> --
>> I do not respond to top-posted replies, please don't ask
>
> Why wasn't it designed using a style similar to templates:
>
> enum class <unsigned long> Val { E1, E2, E3, E4 };

It was designed to follow existing implementations. It is already 
available in MS C++/CLI, and they proposed to use the same syntax for 
ordinary C++.


Bo Persson

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

#9015

On 8/17/2011 8:16 AM, Victor Bazarov wrote:
> On 8/16/2011 11:28 PM, Phil Bouchard wrote:
>> Is it too late to change the strongly type enum?[..]
>
> We have a new Standard (ISO/IEC 14882:2011) as of August 12th, so it's
> late for that one, but there is always the next Standard.

Well I don't think vendors implemented the whole standard already so do 
you think there's any chance a minor modification can be applied?


-Phil

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

#9020

Phil Bouchard  wrote:

> On 8/17/2011 8:16 AM, Victor Bazarov wrote:
>> On 8/16/2011 11:28 PM, Phil Bouchard wrote:
>>> Is it too late to change the strongly type enum?[..]
>>
>> We have a new Standard (ISO/IEC 14882:2011) as of August 12th, so it's
>> late for that one, but there is always the next Standard.
> 
> Well I don't think vendors implemented the whole standard already so do 
> you think there's any chance a minor modification can be applied?

No.
In any case, you might want to try comp.std.c++, that is read by more
members of the committee.

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

#9021

Marc  wrote:

> In any case, you might want to try comp.std.c++, that is read by more
> members of the committee.

Oups, sorry, didn't notice you crossposted widely...

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

#9028

On 8/17/2011 7:16 PM, Marc wrote:
> Phil Bouchard  wrote:
>
>> On 8/17/2011 8:16 AM, Victor Bazarov wrote:
>>> On 8/16/2011 11:28 PM, Phil Bouchard wrote:
>>>> Is it too late to change the strongly type enum?[..]
>>>
>>> We have a new Standard (ISO/IEC 14882:2011) as of August 12th, so it's
>>> late for that one, but there is always the next Standard.
>>
>> Well I don't think vendors implemented the whole standard already so do
>> you think there's any chance a minor modification can be applied?
>
> No.

Well that's definitely something missing because changes are better be 
applied sooner than later.  Now inherited enums can't be implemented in 
the next standard because ':' is already reserved for something else.

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

#9041

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]

#9042

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]

#9043

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]

#9044

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

csiph-web