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: Thomas Klimpel (Thomas.Klimpel_at_[hidden])
Date: 2009-10-17 15:52:29

Howard Hinnant wrote:
> Note that I do not advocate that move-assignment be generally
> implemented as swap.

I know. That's exactly the reason why I tried to understand why move-assignment should not be implemented as swap. More specifically, you wrote once that you initially thought move-assignment could be implemented as swap, but changed your mind later.

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

The check against self-move-assignment would only have to happen in case the test for the existence of resources to destroy succeeded, so it won't cost much performance anyway (at least in theory). So either there is a very good reason why such a check is not necessary, or...

Regards,
Thomas