"Fernando Cacciola" <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
