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-10-17 16:37:10

On Oct 17, 2009, at 3:52 PM, Thomas Klimpel wrote:

>> I generally advise that move assignment be implemented as:
>>
>> 1.  Destroy non-memory resources.
>> 2.  Move assign base classes.
>> 3.  Move assign data members.
>> 4.  Fix up invariants.
>
> The open question is whether "1." should first check for self- 
> assignment before destroying the non-memory resources. My point was  
> that as long as it can't be proved that omitting the check can't do  
> any harm, omitting the check will be risky or worse. I know that it  
> will be no problem if the object is in an empty state, but what  
> about the case where the object is in a non-empty state? And even if  
> we come to the conclusion that we are allowed to omit the check for  
> self-move-assignment, would we be allowed to assert against self- 
> move-assignment from a non-empty object?

I don't believe the standard should really tell you, much less try to  
enforce, how you write your move assignment operator.  The standard  
should give you guidelines on what it is supposed to do, and how it  
might be used within the std::lib, and that's about it.  I think it  
would be safe for the std::lib to promise you that it won't self-move- 
assign your objects, with the possible exception of you calling  
std::swap(x, x).  If std::reserve called swap(x, x), I would consider  
that a bug in std::reserve.

Yes, you should be allowed to check for self-move-assignement, or  
assert on it, or whatever is best for your code.  You should probably  
refrain from self-move-assigning std types such as vector.

-Howard