Re: [boost] [config] Need a slightly different BOOST_STATIC_CONSTANT

From: Cromwell Enage (sponage_at_[hidden])
Date: 2007-04-30 18:58:36

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