2012/1/4 Vicente Botet <vicente.botet@wanadoo.fr>

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-const...

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