Re: [boost] Preprocessor: documentation comment

From: Vesa Karvonen (vesa_karvonen_at_[hidden])
Date: 2002-06-16 12:15:47

Paul Mensonides:
>>I'll have to trust you on that. FWIW, reports from the field indicate some
>>anecdotal compilation slowdown from recent changes.
>
>How serious?  It is somewhat of a trade off between three things:  ease of 
>use,
>ease of implementation, and compilation speed.  'Automatic recursion' does 
>carry
>a price for the gains in ease of use.

Many of the recent changes cause compilation slowdown, because the new 
macros are not yet optimized, but this should change in the future.

>The problem here is not showing how something *can be* used, it is showing 
>what
>types of things it *can be used for* in the scope of a larger system. 
>Building
>blocks are pretty useless without a larger understanding of how to put them
>together to make something useful. In its own way, preprocessor
>meta-programming is almost an entirely separate language and programming
>paradigm, and that is hard to pin down with documentation.

Preprocessor metaprogramming is very much like programming in a strict, 
purely functional programming language. This will be even more true once the 
new techniques will be fully incorporated and the user doesn't have to pay 
so much attention to preprocessor limitations.

>#define IS_FUNCTION_TESTER(N,_)\
>  template<class R BOOST_PP_COMMA_IF(N) BOOST_PP_ENUM_PARAMS(N, class A)>\
>  yes_type is_function_tester(R (*)(BOOST_PP_ENUM_PARAMS(N,A)));
>
>BOOST_PP_REPEAT_2ND(BOOST_PP_INC(MAX_IS_FUNCTION_TESTER_PARAMS),IS_FUNCTION_TESTER,_)
>#undef IS_FUNCTION_TESTER
>
>This could be 'simplified' by the library itself.  A function-type (or 
>pointer,
>etc.) is a common enough structure that the library should support it 
>directly:
>
>#define IS_FUNCTION_TEST(n, _) \
>    template<BOOST_PP_LIST_FUNCTION_ARGS(n, R, A)> \
>    yes_type is_function_tester(BOOST_PP_FUNCTION_PTR(n, R, A));

In my opinion, the preprocessor library should support preprocessor 
metaprogramming. This support should be in the form of generic, higher-order 
macros that either:
- enhance the preprocessing abilities of the preprocessor (e.g. CAT, 
STRINGIZE, REPEAT), or
- enhance the computational abilities of the preprocessor (by making it into 
a complete programming language).
The preprocessor library should not degenerate into a collection of special 
case macros for special cases encountered by C++ programmers. Instead the 
preprocessor library should make it significantly easier to build 
application specific macros for the special cases needed by the application 
developers. Of course, the library should and does offer some support for 
C++ language constructs.

-Vesa

_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com