Re: [boost] [range/iterators/algorithms/phoenix/bind...] Coordinated Approach

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