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

From: David Abrahams (dave_at_[hidden])
Date: 2003-01-31 13:30:12

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

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

> Unfortunately, while I was just about to release the library for
> formal review, I tested it with gcc3.2 and stumped into the
> following:
>

<snip>

> The errors show that the problem is related to the definition of next,prior:
>
>     typedef integral_c<T, (value + 1)> next;
>     typedef integral_c<T, (value - 1)> prior;
>
>
> Solution:
>
> There are two possibilities AFAICT:
>
> (a) since there is int_c<> already, remove next/prior from integral_c
> altoghether.
> (b) add a special enum_c<>.

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;

-- 
                       David Abrahams
   dave_at_[hidden] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution