Thats a bad idea if the enum type does not contain all possible or'ed values as values. With enum {A=1, B=2} A|B=3 is not an enum value so or'ing them is obscure code. For that I have build a small constexpr template class that combines the enum values and returns an underlying integer.

Udo: If your enum is intended as a bitmask then A|B is just that, and you can then test the bits with x&A and so forth. Returning an integer from combined bitmask values doesn't make it any more meaningful.

I find it *less* meaningful to return an integer: a bitmask value that holds A|B but is still the same type conveys to me the idea that this is a particular type of value, and the individual bits (which can be tested with &) have meaning, whereas an integer that holds the numerical value of A|B is much less clear. If I see an integer in a function signature then I have to read carefully the function documentation to see what it means. If I see a bitmask type then I know immediately what it means. YMMV

I distinguish between enumerations (one of several) and enum as flags (zero or more combined).

> whereas an integer that holds the numerical value of A|B is much less clear

Therefore TEnumBits<TMyEnum> holds the value, used as parameter for the consumer. Ergo void f(TEnumBits<TMyEnum>); f(A|B) but not f(3) or TEnumBits<TMyEnum> f();

I like the original use of operators to make an "enum class" enum easier to use, and the use of templates to avoid typing the same things over and over.

You might consider using "constexpr" on the declaration of operator|, operator&, operator^, and operator~, and using "inline" on the declaration of operator|=, operator&=, and operator^=. Maybe this could help avoid multiple definition issues?

I just posted something similar to a website that linked to here. Essentially my argument clarified the one above:

When you write

Colour p = Colour::red | Colour::green;

you assign a value to p that is not in the range of Colour.

This is not the case if you use the legacy C-style way of doing things, ie Colour values defined as an enumeration or as const int, and the associated bitmap defined as a separate unsigned value. Here, the values of Colour and the Colour bitmask itself are two separate (but related) concepts (note that they have two distinct types), whereas the data structures and methods you suggest tacitly unite those concepts, which in my opinion is incorrect. Instead of an enum class and associated methods, perhaps bitmasks and their values could better be expressed as a C++ class or maybe two C++ classes (one for a typesafe enum and one for a bitmask that operates on a typesafe enum). This way we can continue to separate the bitmask from the enumerated values. The end result should look like this:

Colours p = Colour::red | Colour::green;

Note that p is a Colours (plural) type, while the enum values are singular Colour.

This way if I returned Colour from a method, you would know I am returning red or green, as opposed to returning Colours, implying there could be more than one Colour represented (which is misleading to the caller and is what I would call a 'fat' interface).

Let me really bring home my point with an example. Consider the method:

Colour SomeClass::SomeMethod() { //perform some calculations return Colour::red; }

Now let's say somewhere else in the code someone writes:

if (obj.SomeMethod() == Colour::red || obj.SomeMethod() == Colour::green) //do something useful

This will work fine right now. But, given your design, I could easily change SomeMethod to return Colour::red | Colour::green. There is nothing forbidden about doing this, the design specifically allows for it, but the above if statement will evaluate to false when almost certainly it should continue to evaluate to true. This is because one programmer treated Colour as the enum class that it is, and the other programmer treated Colour like the bitmask that it is.

@lbj: You can use a class if you like. I find the enum class with bitmask operations a useful technique. If it doesn't work for you don't use it.

With regards to the set of values and direct comparisons against constants, this is an issue of documentation. If someone treats a bitmask type as if it can only have specific values and not ORed values then they are using it wrong. This is why I made the bitmask operators opt-in: they don't apply to all enum classes.

Call your enum class "Colours" if it helps so you have Colours::red and Colours::green and Colours::red | Colours::green.

>> I find the enum class with bitmask operations a useful technique. If it doesn't work for you don't use it.

I think that the bitmask problem is worth solving, ie people need to use *something*. You solution is not without merit, and I think with some tweaks it would really be complete, and then I would certainly use it without reservation.

>> With regards to the set of values and direct comparisons against constants, this is an issue of documentation.

I can make the same claim about the original C-style bitmask solution, which was unsatisfying enough to motivate this very article. Robust solutions are tough to break/misuse and easy to debug should a break occur. The solution you provided is easy to misuse. "Please refer to the documentation" should be very much avoided if at all possible, and indeed it is very possible in this case.

Whether or not you want to address the shortcomings of this design is up to you. I hope you do because then the C++ community would have a robust solution to a common problem that I have not seen solved anywhere else (granted I have not looked that hard).

I have a better solution (I think), you can find it in my header-only base API "Z": github.com/redcode/Z

Abstract template enumeration class:

template <class T> struct Enumeration {

T value;

inline operator bool() const {return value;}

inline operator T() const {return value;}

inline bool operator ==(T value) const {return this->value == value;} inline bool operator !=(T value) const {return this->value != value;}

inline T operator ~() const {return ~value;}

inline T operator &(T value) const {return this->value & value;} inline T operator |(T value) const {return this->value | value;} inline T operator ^(T value) const {return this->value ^ value;}

inline Enumeration &operator &=(T value) {this->value &= value; return *this;} inline Enumeration &operator |=(T value) {this->value |= value; return *this;} inline Enumeration &operator ^=(T value) {this->value ^= value; return *this;} };

#if __cplusplus >= 201103L

# define TYPED_ENUMERATION_BEGIN(Type, UnderlyingType) \ struct Type : Enumeration<UnderlyingType> { \ inline Type() {} \ Z_INLINE_MEMBER Type(UnderlyingType value) {this->value = value;} \ enum Values : UnderlyingType {

#endif

Helper macros:

#define ENUMERATION_BEGIN(Type) \ struct Type : Enumeration<int> { \ Z_INLINE_MEMBER Type() {} \ Z_INLINE_MEMBER Type(int value) {this->value = value;} \ enum {

#define ENUMERATION_END };};

Then you simply can do:

TYPED_ENUMERATION_BEGIN(WindowMode, uint8_t) RESIZABLE = 1, FULL_SCREEN = 2, PRESERVE_ASPECT_RATIO = 4 ENUMERATION_END

or

ENUMERATION_BEGIN(WindowMode) RESIZABLE = 1, FULL_SCREEN = 2, PRESERVE_ASPECT_RATIO = 4 ENUMERATION_END

> The lack of implicit conversions are particularly useful here, as it means that you cannot pass raw integers such as 3 to a function expecting a scoped enumeration: you have to pass a value of the enumeration

This is true even for plain enumerations though. The difference is in lack of implicit casts in the other direction.

Agreed. I have clarified the section.

I have the similar solution in my project, but based on boost.preprocessor and with the operator << implementation.

The great solution, but I would rename trait to is_bitmask_enum and derive its specifications from std::true_type (where the primary template is derived from std::false_type). I.e. the same way as standard trait is_error_code_enum is implemented (http://en.cppreference.com/w/cpp/io/io_errc/is_error_code_enum).

Shame on my hastle. Please read specialization instead of specification and the right link is http://en.cppreference.com/w/cpp/error/error_code/is_error_code_enum

This is very useful. The only problem I had with the idea of specializing a template is that the template must be specialized in the same namespace as the original template, so this fails:

<pre><code class="language-cplusplus"> namespace foo { enum class my_bitmask { ... }; template&lt;&gt; struct enable_bitmask_operators&lt;my_bitmask&gt;{ static constexpr bool enable=true; }; } </code></pre>

I would have to close my namesspace and put the enable_bitmask_operators specialization at global scope.

In my code I have now instead used a constexpr function:

<pre><code class="language-cplusplus"> template&lt;typename E&gt; constexpr bool enable_bitmask_operators(E) { return false; }

template&lt;typename E&gt; typename std::enable_if&lt;enable_bitmask_operators(E()),E&gt;::type operator|(E lhs,E rhs){ </code></pre>

So now I can place my overloaded function at namespace scope and ADL will find it.

<pre><code class="language-cplusplus"> namespace foo { enum class my_bitmask { ... }; constexpr bool enable_bitmask_operators(my_bitmask){ return true; } } </code></pre>

We'll see how well my code makes it into the comments :)

Yes, it might make sense to name it after is_error_code_enum.

Using constexpr functions is also a nice idea.

I was thinking that one could allow for both specialization and constexpr functions: have the primary template use the constexpr function.

If the template is not specialized then the constexpr function is used. If that is not defined then there are no bitmask operators, but if it is, and it returns true then the bitmask operators are enabled.

If the template is specialized then the result is what the specialization says.

Of course, that means we are now reserving two names: the template name in the global namespace and the constexpr function name in the namespace of each enum.

I asked a question about this topic on SO, thought you might be interested: http://stackoverflow.com/questions/28423742/getting-constexpr-functions-resolved-without-creating-parameter-objects#28423742

Possibly dumb question, but what's the advantage compared with std::bitset?

std::bitset doesn't give you nice friendly names like std::launch::async or my_colour::red.

True, that's a bug in the API for bitset.