Boost logo

Boost :

From: David Maisonave (boost_at_[hidden])
Date: 2006-01-31 08:36:42

"Peter Dimov" <pdimov_at_[hidden]> wrote in message
> David Maisonave wrote:
> It's not used internally, so there is no need to make it private.
> reset() is
> a simple shorthand for swapping your shared_ptr with a temporary
> default-constructed one, then destroying the temp. You can also achieve
> same effect by assignment.
> p = shared_ptr<T>(); // same as p.reset()

Reading the weak_ptr introduction gave me a misunderstanding of what reset
I thought reset just release the pointer without deleteing it if it was the
last referenced.
If it does delete it when it's the last reference, than it does make sense
to have it public.

> Don't tell me that your smart pointer doesn't support assignment. :-)

It not only supports assignment, but it also has the ability to assign to a
different policy type.

> There is no single canonical use for weak_ptr. It's a versatile tool
> that
> can be used in every situation that matches the above description. Some
> people use for it to break shared_ptr cycles.

I just ran a test on this, and it seems that boost::shared_ptr does result
in leaving memory leak in cycle logic.
However, when I tested my proposed smart_ptr, it does not have this problem.
It's able to correctly destroy the objects even in cycles.
The proposed boost::policy_ptr also has the same cycle problem like
I don't understand why they're not able to resolve this in the destructor
Either I'm missing something in my smart_ptr, or there's some extra wacky
logic in the boost::shared_ptr that's blocking deletion in cycles. (Which I
don't get)

Boost list run by bdawes at, gregod at, cpdaniel at, john at