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

From: Peter Dimov (pdimov_at_[hidden])
Date: 2007-04-17 05:58:54

Ion Gaztañaga wrote:
> Peter Dimov wrote:
>> To get back to shared_ptr, given p and q of type shared_ptr, would
>> you be extremely disappointed if after:
>>
>>     p = move( q );
>>
>> q holds the old value of p instead of being empty?
>>
>> (Note that p may have had a value that you could consider "unsafe"
>> in the context of the valid values of q.)
>
> 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.