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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk