[boost] Re: Re: Re: Intrusive smart pointer

From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2002-04-18 13:15:44

"Peter Dimov" <pdimov_at_[hidden]> wrote in message
news:004901c1e6fd$47750410$1d00a8c0_at_pdimov2...
> From: "David B. Held" <dheld_at_[hidden]>
> > "Peter Dimov" <pdimov_at_[hidden]> wrote in message
> > news:008a01c1e6e7$f46f4010$1d00a8c0_at_pdimov2...
> > > [...]
> > > 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.
> >
> > Do you think Loki::SmartPtr's policy approach can (or should) handle
> > these variations well, or would you recommend a different approach?
>
> Yes, a policy-based design is, IMO, the right approach. I personally
> consider Loki::SmartPtr a bit overdesigned (Storage + Ownership should be
> rolled into one policy) but it works, i.e. covers the above feature space
> AFAIK.
>
I agree that a policy-based design is the right approach. My suggestion was
intended to fill the gap between the current shared_ptr and a policy-based
one. If, however, a policy-based solution is somewhere in the *near* future,
I see no need to provide a fixed intrusive-rc flavor as I suggested.

--
Fernando Cacciola
Sierra s.r.l.
fcacciola_at_[hidden]
www.gosierra.com