RE: [boost] Interest in CPP meta programming library?

From: Aleksey Gurtovoy (alexy_at_[hidden])
Date: 2001-05-22 08:26:28

Vesa Karvonen wrote:
> Actually, these statements of mine aren't quite that 
> conclusive anymore,
> because BOOST_IF(c,THEN,ELSE) makes it possible to avoid the 
> special case
> for the first element.
> 
> In particular, BOOST_IF now makes it possible to implement a 
> conditional
> comma:
> 
>     #define BOOST_COND_COMMA_FUN(i)\
>       BOOST_IF(i,BOOST_COMMA_FUN,BOOST_EMPTY_FUN)(i)
> 
> This means that the user doesn't have to treat the first element as a
> special case:
> 
>     static const int
>       integers_from_1_to_100[] =
>     {
>     #define ELEMENT(i) BOOST_COND_COMMA_FUN(i) BOOST_INC(i)
>     BOOST_REPT(100, ELEMENT)
>     #undef ELEMENT
>     };
> 
> BOOST_IF implementation:
> 
>     #define BOOST_IF(c,T,E) BOOST_IF##c(T,E)
>     #define BOOST_IF0(T,E) E
>     #define BOOST_IF1(T,E) T
>     #define BOOST_IF2(T,E) T
>     // ...
>     #define BOOST_IF256(T,E) T
> 
> Open questions:
> - Are IF, DEC and INC robust enough for production use?
> - Is LIST() now redundant?

All these new operations seem very interesting! IMO, if we allow to pass
extra parameters to REPEAT, they will become superior to both your old
approach and the technique I use, in clarity, intuitiveness and flexibility.
I've tried to reimplement all 'boost::mpl' macros and some other user-level
macros using this new approach, and I can say that I am very satisfied with
the results. For example, my current lengthy implementation of
BOOST_MPL_ENUMERATE_DEFAULT_PARAMS macro:

#define BOOST_MPL_DEFAULT_PARAMETER0(param, value)
#define BOOST_MPL_DEFAULT_PARAMETER1(param, value)     param##1 = value
#define BOOST_MPL_DEFAULT_PARAMETER(n, param, value) , param##n = value
#define BOOST_MPL_ENUMERATE_DEFAULT_PARAMS(param, value) \
BOOST_MPL_ENUMERATE_MACRO_CALLS(BOOST_MPL_DEFAULT_PARAMETER, param, value)

has become this:

#define BOOST_MPL_DEFAULT_PARAMETER(i, param, value) \
BOOST_PREPROCESSOR_COMMA_IF(i) param##n = value

#define BOOST_MPL_ENUMERATE_DEFAULT_PARAMS(param, value) \
BOOST_PREPROCESSOR_REPEAT(15, BOOST_MPL_DEFAULT_PARAMETER, param, value)

and yet retained the same usage pattern as before:

template< typename T
        , BOOST_MPL_ENUMERATE_DEFAULT_PARAMS(class C, null_argument)
        > 
struct switch_on // ...
  {
  };

So I am all in favor of the new technique! There is one issue with the
library that I personally would like to see resolved at this stage, though:
names of the macros. IMO, now they are too short and too generic for macro
names, even with the BOOST_ prefix. I understand that longer names could
cause some portability problems, but still I would prefer to see something
less general/more long in place of BOOST_IF, BOOST_INC or BOOST_DEC. At
least the library name, or some other indication of scope of these macros
should be added, e.g. as I did it in the above example
(BOOST_PREPROCESSOR_IF, BOOST_PREPROCESSOR_REPEAT, etc.). 

Aleksey