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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk