Re: [boost] Preprocessor: documentation comment

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2002-06-14 18:16:44

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

> > There are several alternatives that I'm looking into (and Vesa is
> > also), such as only 'allocating' batches of iterations (i.e. only check
> every 5
> > or 10) or using a binary search (or a weighted binary search, or both) to
> > improve the efficiency of such a strategy.
>
> Sounds promising.

We'll see. :)

> > Of course, this whole preprocessor thing was a huge side-trip from what I
> was
> > working on before (template meta-programming), which in turn was a huge
> > side-trip from what I was working on before that.
>
> Life is a series of those, I think ;-)

Yes, but at some point you can lose track of your fundamental goal and end of
developing tools just for others to meet their fundamental goals!

> We could reduce some of the real-world examples needed by the Boost.Python
> library, if that's any help.

I think it is kind of like math.  Besides basic math, it has no real, practical
application until after you get into higher calculus--then it becomes practical
and much more interesting.

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.

One way or another though, in order to make the library useful outside of the
select few, the documentation *must* be there.  Otherwise, the learning curve is
just too steep to use for something like 'arg_tuple_size'.  A person would just
use an external tool to generate it.  One of the things that the library itself
needs, other than documentation, is levels of use that hide some of the
complexity.  For instance, LIST_CLASS instead of a direct application of REPEAT.
These types of things would significantly shorten the time required to get a
handle on basic facilities of the library.  In particular, they would make the
library *useful* to the beginner.

The 'tutorial' (if it can be called that.) has this example:

#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_TEST
ER,_)
#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));

Paul Mensonides