Subject: Re: [boost] [range] adaptors vs. rvalue to lvalue& binding
From: Bronek Kozicki (brok_at_[hidden])
Date: 2012-03-22 12:20:56
Actually I can see now that my last message contains few errors.
On 22/03/2012 15:44, Bronek Kozicki wrote:
>> So do we want to change boost::sort( Rng& ) to boost::sort( Rng&& )
>> ? That would make boost::sort( std::vector() ) ok.
> I fail to see what's wrong with this. Pointless - yes, but inducing
> runtime errors - no. Although of course I could have missed something.
> Back to your function - perhaps taking unqualified template parameter
> is not the best idea, and if you want to take a range you might want to
... or perhaps not. Taking unqualified template parameter will allow you
to write single function on anything with range-like interface,
including boost::iterator_range itself. So, is there anything wrong with:
template <typename Range>
modifies_range(Range && rng);
>> C++ decided at
>> some point to disallow binding rvalues to lvalue&. I think the reason
>> is that rvalues are inaccessible for the caller, so modifying them is
>> likely a bug.
on second reading I can see that you asked about exactly the opposite
binding, taking the history back to last century :) Hope someone will
find the explanation below helpful, but the context in which I have put
it is obviously wrong - since it only applies to C++11 :)
> no, the reason was different. The function which takes rvalue-reference
> does it in order to apply optimization (move semantics) which is
> often/easily implemented as "stealing" data from its actual parameter.
> If binding lvalues to rvalue-reference parameters was allowed, such
> "stealing" could happen implicitly, on an lvalue parameter, and would
> likely result in runtime errors. As things stand now, you have to be
> explicit about moving data away from lvalues, e.g. by using std::move()
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk