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

Subject: Re: [boost] [mpl] integral_c [type_traits] integral_constant limits
From: Krzysztof Czainski (1czajnik_at_[hidden])
Date: 2013-10-21 10:43:01

2012/1/4 Vicente Botet <vicente.botet_at_[hidden]>

>
> 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
>
>
Hi, I just bumped into this bug with MinGW-4.8, which treats this as an
error.
I use boost-1.54
My simple test case is:
#include <boost/mpl/integral_c.hpp>
typedef boost::mpl::integral_c<int,0x7fffffff>::type next_ovf;
typedef boost::mpl::integral_c<int,0x80000000>::type prior_ovf;

I worked around my test by doing changing linest 74-75 of
boost/mpl/aux_/integral_wrapper.hpp to
    typedef AUX_WRAPPER_INST(
BOOST_MPL_AUX_STATIC_CAST(AUX_WRAPPER_VALUE_TYPE, (::boost::intmax_t(value)
+ 1)) ) next;
    typedef AUX_WRAPPER_INST(
BOOST_MPL_AUX_STATIC_CAST(AUX_WRAPPER_VALUE_TYPE, (::boost::intmax_t(value)
- 1)) ) prior;

This only moves the problem from int to intmax_t, but the workaround works
for me ATM. Could this please be fixed?

I had this idea of fixing it by providing specializations of integral_c for
the limits cases? And the specializations wouldn't typedef the offending
next or prior. Would that work?

I'd have tried that myself, but this integral_wrapper.hpp file and it's
macros scared me away from this idea ;-)

Regards,
Kris