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
> 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
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk