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.