Re: [boost] Metaprogramming: Using static const or enum?

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2003-01-11 22:13:15

----- Original Message -----
From: "David Abrahams" <dave_at_[hidden]>

> >> Now Y<int>::value and Y<double>::value have the same type.  Of course,
> >> you will probably want some additional tools in integral_c<T,N>, like
> >> an explicit conversion to an rvalue of type T.
>       ^^^^^^^^

Misread it, sorry.

> > Well, yes.  If you do that, however, it removes one of the primary
reasons
> > to use enumerations, which is for the syntactic convenience.  The only
> > reason left to use enums is to avoid the static storage of the
> > values.
>
> And to improve compilation and linking speed.

Only if you never use the enumeration type itself as a function template
parameter.

> Not if the conversion were explicit:

> > int main() {
> >     f( is_integer<int>::rvalue() ); // better
> >     return 0;
> > }
>
> That's what I meant all along.  I like your name, 'rvalue'.

;)

> > The only solution that I see is:
> >
> > (bool)is_integer<int>::value && (bool)is_integer<int>::value
>
> Pshaw.  "Doctor, it hurts when I do this"
>
> so-don't-do-it-ly y'rs,

It is not me that would do it.  The use of enumerations--under a
theoretically comforming compiler in this regard--basically tells every user
of Boost what they cannot do when it shouldn't make a difference.  It is,
IMHO, bad for Boost to say, "you can't do this because the implementation
does 'x + y' instead of 'int(x) + int(y)'".  In order to safeguard Boost
from this type of evil, every implementation that does any arithmetic,
bitwise, and logical operations on enumeration values would have to be cast
first.  Likewise, this would put the cast burden on users of the
library--particularly other libraries that use Boost.  That is a bad policy.
As I said before, though, the point is moot because compilers are so
disparate in this area.  At this point, we *have* to use both.

Paul Mensonides