Boost logo

Boost :

From: Mark Borgerding (markab_at_[hidden])
Date: 2000-02-07 15:03:48


And as an added bonus; assignments, copy construction and default
construction all take less time. The savings are between 7% and 20%
less, according to my initial findings.

As far as I can tell, this is because the 'released' bool no longer
needs to be constructed or passed along.

--Mark

"greg colvin" <gcolvi-_at_[hidden]> wrote:
original article:http://www.egroups.com/group/boost/?start=2129
> 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.
>
>


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk