Re: [boost] Preprocessor Library - ATTN: David Abrahams

From: Douglas Gregor (gregod_at_[hidden])
Date: 2002-04-17 15:00:00

On Wednesday 17 April 2002 03:38 pm, you wrote:
> To David Abrahams (specifically)...
>
> > It's not bad, but I don't yet see how to get it to deal with another
> > level of iteration. Repeat 'N' of my macro typically contains a
> > construct like:
> >
> >     <class T1, class T2, ... class T(N-1)>
> >
> > You can't just create make1.h, make2.h,... can you?
>
> I did a little experimenting with this, and I came up with some interesting
> conclusions....
>
> One of the interesting things about the preprocessor meta-programming
> facilities that we have but hardly ever use is that the argument to an
> include directive can be a macro.  That is a powerful facility.  As it
> turns out, you can relatively easily do the above.  As I said before, the
> usage of such a mechanism can get ugly if you take it too far, yet it is
> possible.
>
> 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).

        Doug