[boost] Re: change to linked_ptr release

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2000-02-07 14:37:09

I can live with this one.  Thanks.

From: Mark Borgerding <markab_at_[hidden]>
> "greg colvin" <gcolvi-_at_[hidden]> wrote: 
> original article:http://www.egroups.com/group/boost/?start=2125
> > I still think linked_ptr::release is a dangerous invitation
> > to dangling pointers.
> > 
> 
> Yes, I tend to agree with you, but I think that release is important to
> have.
> 
> Maybe we can all be happy ...
> 
> I have an idea for defining the behavior of a ref-counted smart
> pointer's release().  It would give the user the ability to claim
> responsibility for deletion of the pointer, but only if no other
> references share the object. i.e. unique() returns true.
> 
> so the definition for release becomes
> 
> T* linked_ptr::release()
> {
>   T * origPtr = 0;
>   if ( unique() ) {
>    origPtr = ptr;
>    ptr = 0;// just give it up without deletion
>   }else 
>    reset(0);// take *this out of list, leaving 
>    // responsibility for deletion to other nodes
>   return origPtr;// null if not unique
> }
> 
> This approach tends to err on the side of double deletion, as opposed
> to dangling pointers.  This should be much easier to catch in
> debugging, and possibly less dangerous.
> 
> returning 0 if the object is not unique allows safe code of the form 
> delete mySmartPtr.release();
> 
> This approach could also be implemented for the existing shared_ptr.
> 
> And yet another bonus, this approach would get rid of the bool
> "released" member that increases the size of linked_ptr.