Boost logo

Boost :

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.
>>> struct clone {
>>> typedef AUX_WRAPPER_INST(
>>> };
>>> 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
>>> 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?


View this message in context:
Sent from the Boost - Dev mailing list archive at

Boost list run by bdawes at, gregod at, cpdaniel at, john at