From: David Abrahams (dave_at_[hidden])
Date: 2008-07-02 08:28:38
Eric Niebler wrote:
> David Abrahams wrote:
>>>>> I'm letting users opt-in with reference_wrapper.
>>>> I understand that's the scope you chose. I was only trying to explore
>>>> whether that facility can usefully be pushed a little further so
>>>> that we
>>>> don't lose move semantics inside of forwarded arguments. Well, I guess
>>>> we don't, if we assume everything's an rvalue by default :-)
>>> I'm not sure if changes are needed to better support move semantics, or
>>> what they would be. Feedback is welcome.
>> Basically, if your wrappers copy arguments by default,
> They don't. They could, but I don't think they should, do you?
I'm not entirely sure
>> then it's always
>> safe for wrapped functions to move from arguments unless they are
>> reference_wrappers. We could even make move(x) where x is a
>> reference_wrapper return an lvalue, so it'd be transparent.
> I'm not seeing a win here, at least not for C++03. Little help?
One of the motivations for perfect forwarding in C++0x is that a
forwarding function that simply turns everything into lvalues when it
presents the arguments to the forwarded-to function kills most
opportunities for move semantics (since the main opportunities arise
with non-const rvalues). If we start supporting move semantics in
Boost, it would be nice if our forwarding functions could avoid turning
non-const rvalueness into some kind of lvalueness.
-- Dave Abrahams BoostPro Computing http://www.boostpro.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk