[boost] Re: shared_ptr co-existence with other smart poin

From: Gavin Collings (gcollings_at_[hidden])
Date: 2000-03-03 13:26:10

> It is me again. If I was not clear in my first example, I will use
> yours. In both of your examples, the program would GPF. Why. Reason is
> quite simple. The function parameter is a value parameter, that means
> it took a copy of the callers data. This means two shared_ptr's. The
> one in the function is released, and auto_ptr will then delete the
> object. But when the function returns, the original shared_ptr that
was
> passed as the parameter will want to destroy the object as well. Boom!
> 

Hi Miki,

I think we're at cross purposes regarding the semantics of release(). 
Assuming that we're not talking about the one which is restricted to
use with a reference count of 1, a release() call on one shared_ptr
would signal to all related shared_ptrs not to delete the controlled
pointer.  This could be done for boost::shared_ptr with no space
overhead by using a special reference count value as a flag.

> If we implemented release() to clear pointers of all related
> shard_ptr's, that would change semantics of the shared_ptr as a whole,
> and that is probably not a good idea.

Well, I think that's essentially what I was talking about.  It's true
that the semantics are changed, or rather potentially changed: there
would be a lingering doubt as to whether a release call has pulled the
rug from under your feet.  But the point that I was trying to make was
that the alternative would be to have programmers not use shared_ptr at
all and code work arounds with even worse uncertainties.

Gavin