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

From: Jens Maurer (jmaurer_at_[hidden])
Date: 2000-03-04 06:24:53

"Borgerding, Mark A." wrote:
> Approach #1)
> Notify everybody.
> 
> In this approach, every linked_ptr to a given heap object would be
> nullified.  The problem with this is that it could have unexpected results
> in other threads.

If this happens, you haven't made your software specification
airtight enough anyway: You're passing ownership of the
pointer to some library function out of your control, so
it's always a bug to dereference the pointer afterwards.  Thus,
the null-pointer bang is justified.  This reasoning works
both in the threading and non-threading cases.  To support the
usage "if(p.get()) p->do()" in the threading case would require
to be able to "lock" the pointer (and defer release() operations
in other threads while locked).  This is a new interface
requirement.

> Approach #2)
> "I got mine. Don't worry 'bout his."
> 
> In this approach, a linked_ptr would mark the heap object as non-destroyable
> and nullify itself.  All connected linked_ptrs would still have the ptr, but
> would know not to delete it.

This is the same than approach #1, except that #1 at least gives
you a null-pointer bang, which may help in debugging.  I always
prefer a null pointer over a dangling pointer.

> Aprroach #3)
> release only if unique() is true

> By using the return code of release to find out if the object was the last
> reference, a user can avoid dangling pointers.

We agree on this.

>         -Slight bias toward double-deletion

I don't see why. If release() returns 0, we simply cannot pass
ownership to an auto_ptr<>, so we cannot call our library function.
Where's the "double delete" happening?

> All things considered, the conditional release may be a little less
> powerful, but it is a lot more stable and predicatble than the other
> approaches.

I'm arguing that the case where unique() is true is so rare in real
shared_ptr<> usage that it's purely academic to have an approach #3
release().

Jens Maurer