[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