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

Groups > comp.std.c++ > #295

Re: New strongly type enum... why not use "using"?

Show all headers | View raw

Miles,

>  Using "using" to simply import members from another enum does
>  seem intuitive enough, but having it change the following
>  enumeration values,

It's no worse than this:

enum A
{
    x,
    y = 7,
    z
};

....and I thought it less surprising than this:

enum B
{
     a, // == 0
     using enum A,
     c, // == 1
};

....since it's just syntactic sugar for this:

enum B
{
     a, // == 0
     x = A::x,
     y = A::y,
     z = A::z,
     c, // == A::z + 1
};


And it has the extra benefit of being able to automatically
"count" the members in an enum. But I don't actually care; the
counter could be left unchanged.

>  or modify type-checking rules, seems pretty awkward.

How does it modify the type checking rules? There are no changes
I can see.

>  It's especially awkward for the type-checking changes I mentionedand I
>  think these are very desirable given typical usage

Actually, as Marcel Muller said, the problem with inheritance
is slicing; for example:

struct base_class { int a; };
struct derived_class : base_class { int b };

void s1(base_class);
void s2(derived_class d) { s1( d ); }
void s3() { s3( derived_class {} ); }

enum class base_enum { a };
enum class derived_enum : base_enum { b };

void f1(base_enum);
void f2(derived_enum d) { f1( d ); }
void f3() { f1( derived_enum::b ); }


The case with enums should be analogous to the case with
classes - if it's just inheritance. When s3() is called,
everything is fine; s1() is handed a sensible copy of
base_class. But what happens when f1() is called?

In my code I can find two cases:

case 1) f1() wouldn't understand the new constants and would
go into an error recovery mode - e.g. throw an exception.

There is no way for it to get a useful value of the "base
enum", as happens with classes.

In this case, inheritance has gained me nothing. (Well, it's
gained me some trouble - sloppy code lacking proper handling
for illegal enum values has become broken. And I don't want
to spend my time reauditing code.)

case 2) The constants are actually bitmasks and f1() would
work fine. In this case, my code already gets inheritance
through meta programming, e.g.

template<typename Enum>
auto
f4(Enum)
->  typename std::enable_if
<
  mpl::has_key<mpl::set<base_enum,derived_enum>,Enum>::value
>  ::type;

(If need be, this can wrap a function in a library.)

I suspect the above will cope with all the valid "inheritance"
cases.

The real problem is manually keeping enums in sync. If I
was in a forward looking mood, then the code would use a
macro, like this:

#define BIT_CONSTANTS bit0 = 1, bit1 = 2, bit2 = 4

enum C { BIT_CONSTANTS };
enum C_with_bells_on { BIT_CONSTANTS, bit3 = 8 };

So a using-declaration inside enums would remove another use of
the preprocessor.

And then there was the extra benefit of being able to
automatically count enum members.

>  -- because
>  "using ..."  occurs inside the body, so having an effect on the type
>  as a whole is quite weird [what happens, after all, if you put the
>  "using ..." at positions other that the beginning, which is something
>  that the syntax implies is OK, or use "using ..." multiple times?].

The obvious thing happens. It's just syntactic sugar/macro
alleviation.

(And if enums inherit, why not multiple enum "inheritance"?)

>  The thing is that what people are doing here really _is_ "inheritance",
>  so using C++'s usual inheritance syntax seems very natural to me.

To repeat what I said above. I can't find a real-world case
where inheritance of enums would do anything I can't already
do - except import identifiers quickly and easily. So that
was the problem I targeted.

Peter


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/


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

Back to comp.std.c++ | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

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 Phil Bouchard<philippe@fornux.com> - 2011-08-24 14:06 -0700
      Re: New strongly type enum proposal featuring inherited enums Daniel Krügler<daniel.kruegler@googlemail.com> - 2011-08-24 17:39 -0700
        Re: New strongly type enum proposal featuring inherited enums Bart van Ingen Schenau<bart@ingen.ddns.info> - 2011-08-25 20:51 -0600
          Re: New strongly type enum proposal featuring inherited enums =3D?ISO-8859-15?Q?Daniel_Kr=3DFCgler?=3D <daniel.kruegler@googlemail.= com> - 2011-09-07 11:08 -0700
            Re: New strongly type enum proposal featuring inherited enums Miles Bader <miles@gnu.org> - 2011-09-08 14:46 -0700
              Re: New strongly type enum... why not use "using"? "peter miller"<fuchsia.groan@virgin.net> - 2011-09-12 11:18 -0700
                Re: New strongly type enum... why not use "using"? Miles Bader<miles@gnu.org> - 2011-09-13 09:29 -0700
                Re: New strongly type enum... why not use "using"? "peter miller"<fuchsia.groan@virgin.net> - 2011-09-15 14:13 -0700
  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 Victor Bazarov<v.bazarov@comcast.invalid> - 2011-08-24 14:06 -0700
    Re: New strongly type enum proposal featuring inherited enums Paavo Helde<myfirstname@osa.pri.ee> - 2011-08-24 14:06 -0700
    Re: New strongly type enum proposal featuring inherited enums Francis Glassborow<francis.glassborow@btinternet.com> - 2011-08-24 14:52 -0700
      Re: New strongly type enum proposal featuring inherited enums Phil Bouchard<philippe@fornux.com> - 2011-08-24 17:39 -0700
  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 Phil Bouchard<philippe@fornux.com> - 2011-08-24 14:52 -0700
  Re: New strongly type enum proposal featuring inherited enums Marcel Müller <news.5.maazl@spamgourmet.com> - 2011-08-18 07:52 -0600
    Re: New strongly type enum proposal featuring inherited enums Phil Bouchard<philippe@fornux.com> - 2011-08-23 18:20 -0700
    Re: New strongly type enum proposal featuring inherited enums Phil Bouchard <philippe@fornux.com> - 2011-08-24 14:52 -0700
    Re: New strongly type enum proposal featuring inherited enums Phil Bouchard <philippe@fornux.com> - 2011-08-24 14:52 -0700
  Re: New strongly type enum proposal featuring inherited enums Francis Glassborow<francis.glassborow@btinternet.com> - 2011-08-24 14:06 -0700
  Re: New strongly type enum proposal featuring inherited enums "Bo Persson"<bop@gmb.dk> - 2011-08-24 14:06 -0700
  Re: New strongly type enum proposal featuring inherited enums red floyd<no.spam.here@its.invalid> - 2011-08-24 14:06 -0700
  Re: New strongly type enum proposal featuring inherited enums Seungbeom Kim<musiphil@bawi.org> - 2011-08-24 14:06 -0700
    Re: New strongly type enum proposal featuring inherited enums Phil Bouchard<philippe@fornux.com> - 2011-08-24 17:39 -0700
    Re: New strongly type enum proposal featuring inherited enums Phil Bouchard<philippe@fornux.com> - 2011-08-24 17:40 -0700
    Re: New strongly type enum proposal featuring inherited enums Phil Bouchard<philippe@fornux.com> - 2011-08-24 17:40 -0700

csiph-web