This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [libstdc++ PATCH] TR1 'function' and 'mem_fn' support



On Jan 29, 2005, at 10:52 AM, Chris Jefferson wrote:


Douglas Gregor wrote:
It seems like maintaining the code for TR1 in a set of C generator programs will be significantly harder than their preprocessor-based counterparts. The functional_iterate.h I submitted is annoying to work with (because one has to use macros for parameter lists and such), but it retains the essential structure of C++ code and it's easy to make minor tweaks to the source.

If we're concerned about preprocessing time, we can always preprocess all of the includes of functional_iterate.h for some number of parameters as part of configuration.

I think I probably now agree. The only minor problem I have with the macro-based system is slightly harder to later increase the limit, should someone want to use tuples / function_wrappers / whatever with >10 arguments / elements. I shall however agree with the maintainers on this issue :)

[no need to CC me personally; I'm reading the libstdc++ list regularly now]


It need not be harder to later increase the limit. We could do something similar to what is done for tuples, but generate a file that includes functional_iterate.h N+1 times to support up to N arguments. It looks like this:

<tr1/functional> contains:
#include "functional_iterations.h"

functional_iterators.h is generated by a small script/C program, and contains:
#define _GLIBCXX_NUM_ARGS 1
// define more macros
#include "functional_iterate.h"
#undef _GLIBCXX_NUM_ARGS
// ...


#define _GLIBCXX_NUM_ARGS 2
// define more macros
#include "functional_iterate.h"
#undef _GLIBCXX_NUM_ARGS
// ...

// etc.

I used a trivial little Perl script to create the equivalent code (the patch puts this code directly into tr1/functional).

Another solution that would be more work would be to duplicate some of the functionality of the Boost.Preprocessor library and then use that. Boost.Function works this way, and allows you to set the BOOST_FUNCTION_MAX_ARGS macro to the maximum number of arguments you want support for. It can range from 0 to 255.

Doug


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]