Re: [libstdc++ PATH] tr1::bind support

[Douglas Gregor <doug dot gregor at gmail dot com>]

On Mar 23, 2005, at 1:06 AM, Benjamin Kosnik wrote:

> > What can we do? For one, we can scale back to 10 parameters across the
> > board. It's the minimum requirement, and although I'd like more
> > parameters it just takes too long to compile. But, we're still 3 times
> > slower than the Boost equivalents. We can try to reduce the header
> > dependencies a bit (for instance, <tr1/functional> ends up including
> > <string>, which includes <algorithm>, etc.) and factor out the core
> > parts of <tr1/functional> that <tr1/tuple> needs, so that it doesn't
> > incur all of that overhead. The long-term solution is probably
> > something like variadic templates, but that's a big undertaking for a
> > potentially esoteric feature that still hasn't been completely defined
> > :)
>
> Thanks for the analysis. I think having the machinery to do more than 
> 10
> parameters, but only actually doing 10 parameters by default is fine.

Easy enough. Boost.Function, for instance, allows one to set the number 
of arguments supported using a macro BOOST_FUNCTION_MAX_ARGS. We could 
have a similar _GLIBCXX_TR1_MAX_ARGS defaulting to 10 and 
user-configurable up to 20 (but changing this could break the ABI, 
depending on how we handle tuple).

> I am leery of the trickery and complexity involved in the current
> implementations of these features, although I consider the implementors
> themselves quite capable. :)

decltype support would drastically simplify the code (e.g., result_of 
becomes trivial and the return types of operator()'s throughout become 
copies of the return statements), variadic templates would eliminate 
the need for preprocessor metaprogramming.,

> Anyway. I've added c++/20599 as a feature request for this.
>
> I'm assuming 200409 (Pre Redmond) N1704 is the best reference?

Yes.

	Doug