Re: [boost] [C++0x] Emulation of scoped enums

Subject: Re: [boost] [C++0x] Emulation of scoped enums
From: Matt Calabrese (rivorus_at_[hidden])
Date: 2009-03-07 12:27:43

On Sat, Mar 7, 2009 at 5:55 AM, Daniel James <daniel_james_at_[hidden]>wrote:

> I would find occasionally writing 'algae(algae::red) | blue' less
> inconvenient than having to write 'BOOST_SCOPED_ENUM(algae)' whenever
> I wanted to use the type.

And the point is that this only further strays from how you use actual
enums. If we are trying to emulate enum functionality, why would we make it
so different to use. Post how you'd write your overloaded operators and how
the definition would work for both an underlying emulated scoped enum
implementation and an underlying native scoped enum implementation -- you're
going to have to be overly verbose otherwise it won't work for both
implementations. Another subtle issue is for you to show how you'd write a
switch statement using the enum -- now that you have a class-type, you can't
use instances of it as an argument to switch directly without first casting
your "enum" to an actual enum (or calling a named function a that returns
the same value for a native implementation and returns the underlying enum
value for an emulated one). There is also the template problem I pointed out
earlier. All of this means that with such an implementation you still have
to provide a way to get the actual underlying enum type or value if you want
to be able to use it in all of the ways an enum can be used. In the times
where you need the actual type, you would again have to use a macro or a
separate typedef also generated by the original macro invocation anyway,
which is what you didn't like about the first implementation to begin with.
If the main thing that bothers you is simply that in order to refer to the
type you have to use a macro, then just typedef it once and refer to it that
way.

> Another possibility is to have the values as static members of algae,
> with type algae, which would fix your problem but would loose the nice
> syntax for giving the enumerators values.

This is really starting to stray from enums now, and IMO needlessly so. How
would you call the macro in a way that resolves to a scoped enum on
compilers that support scoped enums without using preprocessor sequences or
variadic macros which have all of the pitfalls already mentioned earlier in
this thread? As well, for both implementers and users of the macro, it makes
it much more difficult to support the enum functionality of automatically
setting the enumerated constants' value to 1 greater than than the previous
constant, unless you plan on scrapping that functionality of enums entirely.

> > Another problem is that the type can no longer be referenced as a
> recognized
> > enum type to the compiler, so you can't, for instance, use it directly as
> > the type of a non-type template parameter (instead you would have to use,
> > continuing the example above, color::value, which wouldn't work for
> > compilers that actually support scoped enums).
>
> Not a problem, just always use the emulation.

I think this is the only option if that implementation is to be used, but I
thought the whole point was to make portable scoped enums that use the
native implementation when possible. With all of the different functionality
that this implementation implies and the fact that a scoped enum isn't even
used under the hood when available makes me question if it should even be
called SCOPED_ENUM at all if this route were taken.

> > In the interest of creating the least amount of subtle differences, I
> think
> > leaving the type as an actual enum type is going to be the best solution.
>
> Versus the ADL differences and implicit casts in the original
> solution? Which seem like more serious differences to me.

Actually, the struct solution suggested by Andrey gets rid of the ADL
differences so that is not a problem. Implicit conversion would be the one
remaining difference and all that a user needs to do to make that portable
is add a cast when converting to int and be conscious of everything they are
already familiar with from using regular enums.

-- 
-Matt Calabrese