Boost logo

Boost :

From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-04-19 06:24:41


From: "Fernando Cacciola" <fcacciola_at_[hidden]>
> "Peter Dimov" <pdimov_at_[hidden]> wrote in message
> news:000d01c1e6f7$5b766180$1d00a8c0_at_pdimov2...
> > From: "Fernando Cacciola" <fcacciola_at_[hidden]>
> > > > IMO, there is no "standard" intrusive pointer. The variations are
(at
> > > > least):
> > > >
> > > > * type of count: public variable, accessor functions, base class;
> > > > * name of count/accessors (addref, AddRef, addRef, attach);
> > > > * initial value of the reference count (zero or one.)
> > > > * delete in the pointer or self-delete in release.
> > > >
> > > Still, boost could define at least one of these variations.
> >
> > Sure. Which one? How many complaints will we get that _that one_ was
more
> > appropriate?
> >
> FWIW, I've been designing/re-designing intrusive smart pointers for half a
> decade now for several team-based projects. From my experience, I would
> suggest:
>
> class shared_object

[...]

This is not a smart pointer. ;-)

I've given the intrusive_ptr idea some more thought. It is feasible. My
questions are:

* Do we have a consensus that boost needs an intrusive_ptr that is not
policy based? (IOW is a single variation better than none?)

* How do we decide on the variation? (FWIW the intrusive pointer that I use
is add_ref/release, no base class requirement, initial value zero,
self-deleting. I can provide a rationale.)

* Do we need a formal review for intrusive_ptr? (assuming the above have
been answered.)

The killer feature will be that intrusive_ptr<T>, where detail::counted_base
is a base class of T, will be implicitly convertible to shared_ptr.


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