RE: [boost] PREPROCESSOR library review

From: Aleksey Gurtovoy (alexy_at_[hidden])
Date: 2001-07-09 10:55:05

I think that the PREPROCESSOR library should be accepted into boost.

IMO the library is very useful, and there is a lot of code out there that
could benefit from deploying it to avoid manual code repetition and to get
often needed (and often lacking) configurability. Also, although there are
several different ways to deliver the current functionality of the library
(see, for example, the original Vesa's proposal,
http://groups.yahoo.com/group/boost/message/12032, and 'boost::mpl'
library's approach, http://groups.yahoo.com/group/boost/message/12108), I
believe that library's current design provides a very flexible and elegant
way to do it. I also believe that the library is still work in progress, and
that its implementation is subject to changes as our experience with the
library will grow, but I don't think that this should prevent us from
accepting the library, as it's _very_ useful as it is. To prove myself a
technical superiority of the PREPROCESSOR library over the 'boost::mpl'
library's technique :), I reimplemented all 'boost::mpl' macros using it,
and I am more than satisfied with the results.

Now some specific comments:
----------------------------------------------------------------

1) I've compiled the library test under following three compilers, 

  Comeau C/C++ 4.2.45.2 for MS_WINDOWS_x86
  MSVC 6.5
  Metrowerks Codewarrior 6.1 for Windows

and I ran into problems with Comeau; it seems that their algorithm of macro
call invocation is far from ideal, because for the following fragment of
code linear increasing of IS_FUNCTION_HELPER_TEST_MAX's value leads to not
even quadratic but something like exponential increasing of compilation
time! (see the timing data below).

//***
#ifndef IS_FUNCTION_HELPER_TEST_MAX
#define IS_FUNCTION_HELPER_TEST_MAX 40
#endif

typedef char yes_type;

#define IS_FUNCTION_HELPER(i,A,B)\
  template\
  <BOOST_PREPROCESSOR_ENUM_PARAMS(BOOST_PREPROCESSOR_INC(i),class P)>\
  yes_type is_function_helper(\
    P0
(*)(BOOST_PREPROCESSOR_ENUM_SHIFTED_PARAMS(BOOST_PREPROCESSOR_INC(i),P)));

BOOST_PREPROCESSOR_2ND_REPEAT(BOOST_PREPROCESSOR_INC(IS_FUNCTION_HELPER_TEST
_MAX),IS_FUNCTION_HELPER,A,B)

#undef IS_FUNCTION_HELPER
//***

Timing data
-----------------------

Comeau C/C++ 4.2.45.2 for MS_WINDOWS_x86:
10 parameters < 1 sec
20 parameters ~ 2 sec
30 parameters ~ 15 sec
40 parameters ~ 50 sec

MSVC 6.5, Metrowerks Codewarrior 6.1 for Windows:
10 parameters < 1 sec
20 parameters < 1 sec
30 parameters < 1 sec
40 parameters < 1 sec

Of course, this is not a problem of the library (I am going to report the
problem to the vendor), I just wanted to mention it because it might be
worth to be noted in the documentation, and, if Comeau on Linux has the same
problem (it probably does), we might want to (conditionally) define
IS_FUNCTION_HELPER_TEST_MAX to something like 10 in order to avoid quite
long delay during execution (i.e. compilation) of the test.

2) As I mentioned before, I would like to see high-level library macros like
BOOST_PREPROCESSOR_ENUM_PARAMS,
BOOST_PREPROCESSOR_ENUM_PARAMS_WITH_A_DEFAULT, etc. to use full words
instead of abbreviations, but without PREPROCESSOR prefix, e.g.
 
BOOST_ENUMERATE_PARAMETERS
BOOST_ENUMERATE_DEFAULT_PARAMETERS
...

IMO these macros are general and useful enough to be made top-level (i.e. to
be spelled without library's prefix); also, it makes them more readable (and
short :).

3) Library's documentation is not bad, but it seems that a lot of useful
information that appeared in Vesa's postings to this list hasn't been
included there. In particular, I think that original Vesa's post
(http://groups.yahoo.com/group/boost/message/12032), with appropriate
changes, could make a good "Motivation" section (I don't think "Tutorial"
covers this well), and summary of the library that was posted as part of the
review announcement (http://groups.yahoo.com/group/boost/message/13911)
(more specifically, the LIBRARY PRIMITIVES section) IMO should migrate into
the docs too.

Less significant issues with docs:

a) I also think that macro names in examples should be complete, e.g.
BOOST_PREPROCESSOR_COMMA_IF instead of (currently) COMMA_IF.
b) Explanation of some tricky issues with the macro replacement and argument
substitution would be beneficial (to users). E.g. why one need to write:

#define SOMETHING(i, unused1, unused2)                        \
    BOOST_PREPROCESSOR_IF(i, DO_SOMETHING, DO_NOTHING)(i)     \
/**/
BOOST_PREPROCESSOR_2ND_REPEAT(10, SOMETHING, unused, unused)

instead of:

#define SOMETHING(i, unused1, unused2)                        \
    BOOST_PREPROCESSOR_IF(i, DO_SOMETHING(i), DO_NOTHING(i))  \
/**/
BOOST_PREPROCESSOR_2ND_REPEAT(10, SOMETHING, unused, unused)

c) May be less complex examples in tutorial (ones that do not involve
template metaprogramming) are needed.

Aleksey