Boost logo

Boost :

From: Peter Dimov (pdimov_at_[hidden])
Date: 2003-10-09 09:46:14


Alexander Terekhov wrote:
> Peter Dimov wrote:
>>
>> Alexander Terekhov wrote:
>>> Peter Dimov wrote:
>> [...]
>>>>> ... and never actually do a reset, to begin with.
>>>>
>>>> This is known and expected. reset() is assumed to give the basic
>>>> guarantee.
>>>
>>> That makes no sense to me.
>>
>> Heh. I don't care. Most of what you post makes no sense, you still
>> expect us to parse it. Look it up.
>
> I did.
>
> "void reset(); // never throws
> Effects: Equivalent to shared_ptr().swap(*this)."
>
> "shared_ptr(); // never throws"
>
> "void swap(shared_ptr & b); // never throws"

That's shared_ptr::reset. p_ is not necessarily a shared_ptr. The technique
describes how a deleter can be used to hold another smart pointer.

The code as written assumes that p_.reset() is nothrow. The catch(...)
suggestion is for the case where p_.reset() only gives the basic guarantee.

>>>> If the reset() attempt fails, the fallback is that the pointer will
>>>> be destroyed later, when all weak pointers die.
>>>
>>> And what if throws later as well?
> ^
> |
> it ------------+
>
>>
>> What if _what_ throws?
>
> Damn. *p_.reset();*

p_.reset() is only executed once, in operator(). Later the deleter is simply
destroyed, p_ is a member, it's destroyed too.

> You wrote: "If this is not the case, p_.reset() should be wrapped in
> a try {} catch(...) {} block that ignores exceptions. In the (usually
> unlikely) event when an exception is thrown and ignored, p_ will be
> released when the lifetime of the deleter ends." Nevermind that you
> also wrote "~weak_ptr(); Effects: Destroys this weak_ptr but has no
> effect on the object its stored pointer points to.".

That is correct. ~weak_ptr does not destroy the object (invoke the deleter),
but it can destroy the deleter, if *this is the last remaining reference to
it.


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