Re: [boost] Why does shared_ptr have a public reset() method

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

"Peter Dimov" <pdimov_at_[hidden]> wrote in message
news:<00f101c62659$d1264990$6507a8c0_at_pdimov2>...
> 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
the 
> same effect by assignment.
> 
> p = shared_ptr<T>(); // same as p.reset()

Reading the weak_ptr introduction gave me a misunderstanding of what reset
does.
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
boost::shared_ptr.
I don't understand why they're not able to resolve this in the destructor
call.
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)