Re: [libstdc++ patch] TR1 reference_wrapper invocation, base classes

[Paolo Carlini <pcarlini at suse dot de>]

Hi Doug,

> This patch adds support for reference_wrapper invocation and introduces the 
> right base classes and typedefs for reference_wrapper. It builds on (but does 
> not include) the result_of patch I sent previously 
> (http://gcc.gnu.org/ml/libstdc++/2005-02/msg00250.html) and fixes one bug in 
> that patch: result_of did not do the right thing for member data pointers, 
> but now it does.
>
> The repetition code in tr1/functional that includes tr1/functional_iterate.h 
> many times has been moved into tr1/repeat.h, because it is needed for files 
> other than tr1/functional_iterate.h; you now define a macro 
> (_GLIBCXX_REPEAT_HEADER) and include tr1/repeat.h when you need to repeat 
> code.
>  
Great. This is also absolutely fine with me, thanks a lot!

> There is a _lot_ of metaprogramming in this patch; much more so than I had 
> expected, and that makes the code a little bit hairy. There are two major 
> complicating factors:
>  (1) reference_wrapper<T> derives from unary_function and/or binary_function 
> when possible. This happens when the type T is a free or member function 
> pointer, function type, or class type derived from unary_function and/or 
> binary_function. I've tried to document all of the metaprogramming I had to 
> do to get those right, and included the tricky test cases I could think of. 
>
>  (2) reference_wrapper<T>::operator() has to deal with invoking member 
> pointers (by wrapping in mem_fn), function objects, and function references. 
> There is some SFINAE/enable_if magic in the __invoke function to decide 
> between these options.
>  
One very minor comment: maybe we should add, as an extension, 
__enable_if to the tr1/type_traits header? I gather that you are 
currently forced to include cpp_type_traits.h only for enable_if and 
adding it to tr1/type_traits would bring us one step closer to the 
single "type_traits" header, that we want long term...

Paolo.