Re: [boost] [shared_ptr] auto_ptr interfaces

From: Yuval Ronen (ronen_yuval_at_[hidden])
Date: 2005-12-14 07:27:26

Yuval Ronen wrote:
> Peter Dimov wrote:
> 
>>Yuval Ronen wrote:
>>
>>
>>>Hi.
>>>I wondered what the reason that there is a 'operator=(auto_ptr<Y>&)'
>>>but there isn't any 'void reset(auto_ptr<Y>&'. This seems to me as
>>>asymmetry.
>>>
>>>At first I thought the reason that reset(Y*) is supplied instead of
>>>operator=(Y*), is that Y* assignment needs to be explicit (as the
>>>constructor is explicit) and operator= doesn't allow explicity (is
>>>there
>>>such a word?). But if this assumtion is correct, then there is
>>>contradiction between the constructor for auto_ptr, which is explicit,
>>>and the operator= for auto_ptr, which is not explicit. Am I talking
>>>nonsense?
>>
>>
>>No, you make a lot of sense, and reset(auto_ptr&) indeed seems more 
>>consistent than operator=. But it's too late to change that now. :-) 
> 
> 
> Then I guess I'll have to live with it... :-)

Or not...

I just thought that if we combine this with the conclusion of the 
discussion about temporary auto_ptrs being passed to shared_ptr 
constructors (with the '.release()'), then the result is that I can't 
assign a temporary auto_ptr to a shred_ptr.

If I had a reset(auto_ptr<Y> &), then I could call it with .release(), 
but since all I have is operator=(auto_ptr<Y> &), I can't use 
.release(), as I don't have operator=(Y*).

No temporary auto_ptrs for me... :-(