"David Abrahams" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > "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. > 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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
