Boost logo

Boost :

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... :-(


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk