Boost logo

Boost :

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2002-04-17 15:31:37


----- Original Message -----
From: "Douglas Gregor" <gregod_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Wednesday, April 17, 2002 1:00 PM
Subject: Re: [boost] Preprocessor Library - ATTN: David Abrahams
> > The solution hinges on several facts...
> > 1. a macro can be the argument to an include directive
> > 2. a macro can be a parameter to a file, if the 'file' is analogous to a
> > macro then a macro can be analogous to a macro parameter.
> [Snip]
> > Any thoughts?
> >
> > Paul Mensonides
>
> FWIW, Boost.Function and Boost.Signals use this approach. The majority of the
> code for Boost.Function lives in function/function_template.hpp, which
> is parameterized by a bunch of macros containing lists of types, arguments,
> etc. that are needed. The headers function/function0.hpp,
> function/function1.hpp, etc. merely define these macros then include
> function/function_template.hpp.
>
> Also, the Boost.Signals library (not in CVS yet, but it's in the vault)
> defines a similar signals/signal_template.hpp that is parameterized by
> only the number of arguments supported. The header
> signals/signal_template.hpp then includes the appropriate Boost.Function
> header using fact #1 above (e.g., if the signal takes 2 arguments,
> function/function2.hpp will be included).

Good. :) My conclusions are that the BPL should include functionality like this
for the purposes of debugging and error messages, etc.. The inherent problem
with this:

#define SOME_MACRO(C) \
    template< blah blah blah \
        another line \
    };

Is all on one line. <- it is also significantly slower to use macro recursion
exclusively:

#define SOME_MACRO_1(N) N
#define SOME_MACRO_2(N) SOME_MACRO_1(N) N
#define SOME_MACRO_3(N) SOME_MACRO_2(N) N

for instance.

Ideally, you would like some things to be macro recursive (which always ends up
on one line) and some things to be file iterative (which always ends up on
different lines).

Paul Mensonides


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk