Re: [boost] PREPROCESSOR data structures

From: Douglas Gregor (gregod_at_[hidden])
Date: 2001-12-17 16:54:05

On Monday 17 December 2001 04:48 pm, you wrote:
> This is totally cool. However, I have a philosophical problem with the
> preprocessor library (maybe philosophical is the wrong word): If I have to
> debug code generated by the preprocessor library, or even understand the
> source, I'm going to have a hard time. So far, I've been using some Python
> scripts to generate readable, debuggable C++ when neccessary. I also have
> had some practical problems using PREPROCESSOR with Metrowerk's broken
> preprocessor. So, I guess I'm trying to figure out when/where I'd want to
> use Boost.PREPROCESSOR instead of my Python scripts.

Tuples, Function, Bind and MPL would all benefit from using the PREPROCESSOR 
library, though none do (yet...). If they did, the user would be allowed to 
select at compile-time the maximum number of arguments supported (e.g., max 
length of a tuple, max number of arguments supported by Function or Bind, or 
max length of an MPL typelist build non-recursively).

Here's the plan for Boost.Function: all parameter/argument lists will be 
constructed using the PREPROCESSOR library within function_template.hpp. 
Then, the user can choose to create the class boost::function37 that works 
for 37 arguments with:

#define BOOST_FUNCTION_NUM_ARGS 37
#include <boost/function/function_template.hpp>

If the functionN classes _really_ become a macro (e.g., one big macro 
expansion creates the entire contents of 
boost/function/function_template.hpp), then we could even have:

#define BOOST_FUNCTION_MAX_ARGS 37
#include <boost/function.hpp>

This would generate function0, function1, function2, ..., function37 classes 
and an appropriate function type that takes up to 37 argument types and 
derives the appropriate class. I know the PREPROCESSOR library can do it, but 
I don't have the same faith in the preprocessors :)

        Doug