From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2007-04-17 11:46:59
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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk