[boost] Re: gcc3.2, mpl::integral_c<> and enums

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2003-01-31 14:10:45

"David Abrahams" <dave_at_[hidden]> wrote in message
news:uvg05w4sr.fsf_at_boost-consulting.com...
> "Fernando Cacciola" <fernando_cacciola_at_[hidden]> writes:
>
> > Hi, I'm having the following problem (?) with mpl::integral_c.
> >
> > Since it is intended to encapsulate an "Integral Constant",
> > I thought that it somewhat superseded BOOST_STATIC_CONSTANT.
> > IOWs, I figured that if I have something of the form:
> >
> > struct X
> > {
> >   BOOST_STATIC_CONSTANT( Type, ID = Val ) ;
> > } ;
> >
> > it could be rewritten as:
> >
> > struct X
> > {
> >   mpl::integral_c<Type,Val> ID ;
> > } ;
>
>     struct X
>     {
>       typedef mpl::integral_c<Type,Val> ID ;
>     } ;
>
> , maybe.
>
Yes, :-)

> > The benefit is that X::ID becomes a lot more usable on those
> > compilers with poor non-type template parameter support.
> >
> > Specifically, I designed the traits class of the Numeric Conversion
Library
> > to expose mpl::integral_c and mpl::bool_c in place of
BOOST_STATIC_CONSTANT
> > for its different value fields.
> >
> > So, first of all, do you agree that the mpl form is better?
>
> It's "better", but maybe not for the reasons you think ;-).  [It has
> to do with metafunction/metadata polymorphism]
>
Also...
It is a burden to deal with X::value in bcc5.5.1 because you need to fully
qualify X,
but not for X::type, do given that many metafunctions accept mpl's forms
already,
it is better if only for this reason.

>
> I think the fix is much easier than either of those:
>
>     typedef integral_c<T, static_cast<T>(value + 1)> next;
>     typedef integral_c<T, static_cast<T>(value - 1)> prior;
>
Of course! I've tried many _other_ casts (for 'value' and '1' individually),
but not this one...

It works now!

--
Fernando Cacciola