Peter Dimov wrote:
Thinking it twice. Wouldn't simple swap lead to the false impression that the reference count for the object p was pointing was dropped? If p was the last reference to that value, wouldn't the user be surprised if value is not destroyed (with its side effects) just when p is move-assigned? If the user does not destroy q, the value is staying there. OTOH, this could make move-assignment more expensive because it might destroy objects.
This is the essence of the discussion. :-) I think that efficiency is more important in a move primitive than leaving the source in a predictable state, Joe argues the other way.
Sorry, my radar was activated when containers entered in the discussion ;-) I agree with you that efficiency is important for nearly all objects. Containers might also hold resources that would be liberated with the destructors, but I wouldn't want to implement the move assignment as something like clear() + swap(). Implementing move assignments as swap sounds good and I've implemented pseudo-move semantics (based on library emulation) for Interprocess containers using swap for move assignments (see CVS code). My point is that the standard should explicitly say it: "move assignment for this container is the same as swap()". At least we would know what is really happening. If we left that undefined the complexity of a move operation could be terribly varying depending on the implementation, and by consequence, unusable. In a container, for example, operation complexity refers to search and copy, but in node containers destroying values is orders of magnitude slower than doing a search. Information is power. Ion