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: 2012-01-04 07:27:58

Vicente Botet wrote
> 
> ----- Original Message ----- 
> From: "Edward Diener" <eldiener@>
> To: <boost_at_.boost>
> 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@>
>>> To:<boost_at_.boost>
>>> 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&lt;boost::intmax_t, 0x7FFFFFFFFFFFFFFFLL&gt;
>>>
>>> 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?
> 
> 

Any new on the application of this patch? Could I apply my self and commit
in trunk?

Vicente

--
View this message in context: http://boost.2283326.n4.nabble.com/mpl-integral-c-type-traits-integral-constant-limits-tp3042126p4261042.html
Sent from the Boost - Dev mailing list archive at Nabble.com.