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
> passed as the parameter will want to destroy the object as well. Boom!
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk