Re: "Reusable" operator overloading for enum?
On Dec 28, 4:10 pm, James Kanze <james.ka...@gmail.com> wrote:
On Dec 27, 7:30 pm, nick <nick...@fastmail.fm> wrote:
[...]
Marcel, your solution works perfectly. I like how it
'documents' the enum as being a flag set. I'm using this for
now with a few small additions, but now I'm curious why people
seem generally opposed to macros...
Because they don't obey scope. In this case, all of the other
solutions have worse problems, so macros are the way to go,
True, but it sounds a little like apples and oranges... preprocessor
directives don't have any concept of scope or anything else in the
code besides other preprocessor stuff. It wouldn't make sense for
macros to obey scope as scope means nothing to them. I guess it would
be nice if you could put a macro inside of a namespace, but I'm not
sure that's realistic?
This makes me wonder if I should cast to unsigned as in
Marcel's example, or signed as in Saeed's example and as I was
doing before. Of course I'll only want to use positive numbers
for my flag sets, but enums seem to handle negative numbers
just fine, so I'm not sure what the right thing to do is here.
The safest solution is probably just to use unary + for the
conversion, e.g.:
MyEnum
operator|( MyEnum lhs, MyEnum rhs )
{
return static_cast< MyEnum >( +lhs | +rhs );
}
(The unary + operator is an arithmetic operator, so forces the
conversion of the enum into the underlying type, just as -
would.) If this looks too weird or exotic, there's always
"+ 0" instead.
So, I guess my question is: is there a way to explicitly store
an enum as an int, or an unsigned int, or whatever, either
using a language construct or some kind of compiler
instrucion? I'm using GCC 4.3.
I have some template metacode somewhere which evaluates the
underlying type, but IIRC, it's a bit hairy. Most of the time,
you don't need variables of the underlying type, however, and
the unary + trick is sufficient.
--
James Kanze
That + trick is great, it actually makes a lot of sense and doesn't
seem weird at all. In light of your comments and Marcels', I've
revised the macro again...
#define FLAGS_(T) \
inline static T operator * (bool l, T r) \
{ return static_cast<T>(l*+r); } \
inline static T operator * (T l, bool r) \
{ return static_cast<T>(+l*r); } \
inline static T operator | (T l, T r) \
{ return static_cast<T>(+l|r); } \
inline static T operator & (T l, T r) \
{ return static_cast<T>(+l&r); } \
inline static T operator + (T l, T r) \
{ return l|r; } \
inline static T operator - (T l, T r) \
{ return static_cast<T>(+l-(l&r)); } \
inline static T& operator |= (T& l, T r) \
{ return l = l|r; } \
inline static T& operator &= (T& l, T r) \
{ return l = l&r; } \
inline static T& operator += (T& l, T r) \
{ return l = l+r; } \
inline static T& operator -= (T& l, T r) \
{ return l = l-r; }
....I'm pretty happy with it. Thanks for the help!