Boost logo

Boost :

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

> 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 (

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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at