Re: [boost] [mpl] integral_c [type_traits] integral_constant limits

Subject: Re: [boost] [mpl] integral_c [type_traits] integral_constant limits
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2011-01-14 13:56:38

----- Original Message ----- 
From: "Edward Diener" <eldiener_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Monday, January 03, 2011 3:32 AM
Subject: Re: [boost] [mpl] integral_c [type_traits] integral_constant limits

> On 1/2/2011 11:00 AM, vicente.botet wrote:
>> ----- Original Message -----
>> From: "vicente.botet"<vicente.botet_at_[hidden]>
>> To:<boost_at_[hidden]>
>> Sent: Tuesday, November 16, 2010 10:15 PM
>> Subject: Re: [boost] [mpl] integral_c [type_traits] integral_constant limits

>> I have made some modification on Boost.MPL to don't include the prior and next nested types. Instead I have added a 'clone' metafunction that will not be instantiated if not explictly requested and that returns the integral type with a different parameter.
>>
>>      template<AUX_WRAPPER_VALUE_TYPE M>
>>      struct clone {
>>          typedef AUX_WRAPPER_INST( BOOST_MPL_AUX_STATIC_CAST(AUX_WRAPPER_VALUE_TYPE, M) ) type;
>>      };
>>
>> Of course I have needed to change the next and prior metafunctions to use tag dispatch.
>>
>> While running the regression on Boost.MPL I have found a problem: most of the types (iterators) that are used as parameter of next/prior don't have a tag nested type :(. I've added an artificial nested tag type on these types.
>>
>> In this way we are now able to instantiate integral constants with the max and min values without error.
>>
>> boost::mpl::integral_c<boost::intmax_t, 0x7FFFFFFFFFFFFFFFLL>
>>
>> Most of the modified code is protected with the macro BOOST_MPL_NEXT_PRIOR_EXT.
>>
>> I'm not sure this is the best way to workaround this BUG. Please, could you check  the attached patches, and let me know if this patch can be included in trunk with minor modifications?
>>
> 
> My bug report number 3779 is about this also. Please take a look at it 
> to make sure your fix also addresses that bug report. I assume it does 
> from your description above, but I just want to bring it to your 
> attention just in case.

Yes. It seems the same problem. The instantiation of prior or next on the limits cause overflow. While this is a warning on most compilers its been error on gcc-4.6.0 C++0x.

Could the maintainers of Boost.MPL take a look to the patch attached on this thread?

Thanks,
Vicente