On Dec 7, 2007 2:51 AM, Tobias Schwinger <tschwinger@isonews2.com> wrote:
Stjepan Rajko wrote:
Clear enough. I would find the gref metafunction useful factored out in a separate include file (with a more descriptive name than gref like... forwardable<T>::type? lvalue_reference_to_which_is_bindable<T>::type :) ?)
It sorta exists already, as 'gref' is basically a more primitive version of 'call_traits<T>::param_type.
Bah, I was under the misconception that, e.g., call_traits<int>::param_type is int, but it's actually const int... param_type is what I need, thanks.
* What is your evaluation of the implementation?
I agree with Dave on the EBO suggestion (and thanks for the compressed_pair lesson)
From my personal feeling inheriting from 'forward<F>' might be too rare of a use case to optimize for. However, with two reviewers asking for it I'll probably end up drowning my possibly premature assumptions on what the user will or will not do in a sea of genericity :-)...
I tend to be inheritance-happy :-) Are there any arguments against implementing forward<F> using inheritance of (compressed_pair of) F?
* What is your evaluation of the potential usefulness of the library?
Very useful. Although, I seem to run into cases where I want to have a forwarding function (not function object), or a forwarding operator. But maybe I'm wrong in preferring an actual function...
Something like 'make_forward_adapter'?
You mean like 'make_fused', etc...? No, I meant instead of ending up with a function object that does perfect forwarding, ending up with an actual function that does perfect forwarding. But the only way I can see of facilitating that would be factoring out the preprocessing code to make it easier for someone to implement one without code duplication. Best, Stjepan