Boost logo

Boost :

Subject: Re: [boost] [C++0x] Emulation of scoped enums
From: Daniel James (daniel_james_at_[hidden])
Date: 2009-03-07 05:55:17


2009/3/6 Matt Calabrese <rivorus_at_[hidden]>:
>
> One quick example of how this can show up as a problem in seemingly trivial
> code is operator overloading. Imagine a very simple color enum with
> enumerations "red = 1", "green = 2", "blue = 4", and let's say you decide to
> overload operator | to combine colors. If you write the overload using the
> type "color"... as long as at least one of your operands is not one of the
> enumerated constants named directly. For instance, color( red ) | color(
> blue ) works fine, however red | blue would not because the operator was
> overloaded for the encapsulating type as opposed to the nested value type!

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.

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.

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

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

Daniel


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk