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
> 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
> 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.
> 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
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).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk