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

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

On Sep 7, 2009, at 3:26 PM, Christopher Jefferson wrote:

>
> On 7 Sep 2009, at 20:08, Jeffrey Hellrung wrote:
>
>> Howard Hinnant wrote:
>>> Using an experimental C++0x compiler and library (you might can do  
>>> this experiment g++-4.4, I'm not sure) I make this substitution  
>>> and indeed, I get the same output (remove all of the *.dat files  
>>> prior to each run).  This experimental library has:
>>> template <class _Tp, class _Allocator>
>>> inline
>>> vector<_Tp, _Allocator>&
>>> vector<_Tp, _Allocator>::operator=(vector&& __x)
>>> {
>>>   clear();
>>>   swap(__x);
>>>   return *this;
>>> }
>>
>> Perhaps a dumb question, but isn't the above incorrect under self- 
>> assigment (x = move(x))?  Is there a "standard way" or "recommended  
>> guideline" for handling self-assignment in the move assignment  
>> operator, or is this a nonissue?
>
> I'm actually not 100% positive what the intended semantics of x =  
> move(x) are, but clearly as a QOI issue it should behave.
>
> Most people put:
>
> if(&__x != this)
>
> or something similar in normal assignment operators, adding it also  
> to all move operators seems very sensible.

My hope has been to make x = move(x) undefined behavior.  Rationale:   
The move assignment operator should be fast enough that an extra if- 
test may adversely impact performance (above the noise level).  The  
philosophy has been that code should be able to assume that if given  
an rvalue, then it /really/ is an rvalue.  And if the client lied by  
moving an lvalue, then it is up to the client to make sure that lie is  
really safe.  And if the rhs /really is/ an rvalue, then self  
assignment is impossible.  After all, one of the primary motivations  
for move semantics is performance.  So I'd really like it to be as  
fast as possible.  The slower it is, the less important it is.

The draft standard could probably use a statement to that effect.   
Currently the closest thing in there with regards to this issue is  
[container.requirements.general]/12:

> An object bound to an rvalue reference parameter of a member  
> function of a container shall not be an element of that container;  
> no diagnostic required.

-Howard