[config] Need a slightly different BOOST_STATIC_CONSTANT
Hi, I have a snippet of code that looks something like template< std::size_t N > class something { static const std::size_t count = N; }; On the RVCT 2.2 compiler this fails to compile with an internal error. The obvious workaround, and the one chosen by BOOST_STATIC_CONSTANT is template< std::size_t N > class something { enum { count = N }; }; This compiles but through probably another compiler bug during SFINAE overload resolution with a streaming operator called with a type of something it trys to instantiate say boost::is_pod< something<0>::(unamed)
, fails and the compilation aborts. The workaround for this is to name the enumeration.
template< std::size_t N > class something { enum stupid_name_for_rvct { count = N }; }; This works fine and I've been using it for a while. However I'm now porting to MinGW GCC and I have SFINAE overloads which compare for instance something<0>::count to something<1>::count. MinGW gives a slew of warnings and eventually aborts the compilation. Using the static const std::size_t implementation of count it works fine. Sorry for speaking about the problem in such an unclear way but at the moment I don't have a simple reproducable case. This is basically the problem that BOOST_STATIC_CONSTANT was designed to solve IIUC but I need it to name my enumerations for me under RVCT. Perhaps something could be done using a slightly decorated line number. This would restrict you to one use of BOOST_STATIC_CONSTANT per line but that seems perfectly acceptable to me. Thanks, Michael Marcin
--- Michael Marcin wrote:
The workaround for this is to name the enumeration.
template< std::size_t N > class something { enum stupid_name_for_rvct { count = N }; };
[snip]
This is basically the problem that BOOST_STATIC_CONSTANT was designed to solve IIUC but I need it to name my enumerations for me under RVCT. Perhaps something could be done using a slightly decorated line number. This would restrict you to one use of BOOST_STATIC_CONSTANT per line but that seems perfectly acceptable to me.
Unfortunately this restriction would make BOOST_STATIC_CONSTANT statements unusable from within a Boost.Preprocessor repetition construct, e.g.: #define PRED(r, state) \ BOOST_PP_NOT_EQUAL( \ BOOST_PP_TUPLE_ELEM(2, 0, state) \ , BOOST_PP_INC( \ BOOST_PP_TUPLE_ELEM(2, 1, state) \ ) \ ) \ /**/ #define OP(r, state) \ ( \ BOOST_PP_INC( \ BOOST_PP_TUPLE_ELEM(2, 0, state) \ ) \ , BOOST_PP_TUPLE_ELEM(2, 1, state) \ ) \ /**/ #define MACRO(r, state) \ BOOST_STATIC_CONSTANT( \ int \ , BOOST_PP_CAT( \ N \ , BOOST_PP_TUPLE_ELEM(2, 0, state) \ ) \ = BOOST_PP_TUPLE_ELEM(2, 0, state) \ ); \ /**/ BOOST_PP_FOR((5, 10), PRED, OP, MACRO) Some MPL.Math metafunctions are implemented in terms of this type of code, for example. Reverting them back to template-based implementations as a workaround would cause compile times to skyrocket again. Cromwell D. Enage __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
participants (2)
-
Cromwell Enage -
Michael Marcin