Re: [boost] [move][container] Review Request (new versions ofBoost.Move and Boost.Container in sandbox and vault)

Subject: Re: [boost] [move][container] Review Request (new versions ofBoost.Move and Boost.Container in sandbox and vault)
From: Howard Hinnant (howard.hinnant_at_[hidden])
Date: 2009-09-07 17:10:13

On Sep 7, 2009, at 4:44 PM, Peter Dimov wrote:

>> My hope has been to make x = move(x) undefined behavior.
>
> I find this a bit hard to justify.
>
>> Rationale:
>> The move assignment operator should be fast enough that an extra if-
>> test may adversely impact performance (above the noise level).
>
> The problem with making it UB is that y = move(x) now needs to be  
> guarded with if( &x != &y ) everywhere in client code. Sometimes the  
> user will know that x is not y, but is this really the case most of  
> the time?

It has been part of the design for the past 7 years.  From N1377  
(2002-09-10):

> Move semantics will automatically come into play when given rvalue  
> arguments. This is perfectly safe because moving resources from an  
> rvalue can not be noticed by the rest of the program (<em>nobody  
> else has a reference to the rvalue in order to detect a difference</ 
> em>).

Here it is again in N1690 (2004-09-07):

> When the argument is an rvalue, the author of the class knows that  
> he has a unique reference to the argument.
>
> The overload taking an rvalue can modify the argument in whatever  
> invariant preserving way it pleases and be guaranteed that the rest  
> of the program will not notice!

I'm currently thinking that we need a Chapter 17 statement along the  
lines of:

    The C++ standard library may assume that an rvalue reference  
represents a unique reference to the bound object.

This statement would have been more difficult to write the standardeze  
for prior to N2831 (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2831.html 
).

This would make [container.requirements.general]/12 redundant, and  
that paragraph could thus be removed.

This would also mean that for every class type defined by the standard  
library with a move assignment operator:

C& C::operator=(C&& rhs);

This signature may assume that rhs represents the only reference to  
the object bound to rhs.  After all if the library can't assume (for  
example) that in

    vector::push_back(T&& t);

t is a unique reference to some object, then it can't very well  
destructively modify that object while appending it to the vector.

-Howard