From: Stjepan Rajko (stipe_at_[hidden])
Date: 2007-12-07 15:50:00
On Dec 7, 2007 2:51 AM, Tobias Schwinger <tschwinger_at_[hidden]> 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