[libstdc++ PATH] tr1::bind support

Douglas Gregor doug.gregor@gmail.com
Wed Mar 23 12:52:00 GMT 2005


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



More information about the Libstdc++ mailing list