Re: [boost] [shared_ptr] dangerous implementation of moveconstructor

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