[boost] Re: Re: Intrusive smart pointer

From: David B. Held (dheld_at_[hidden])
Date: 2002-04-18 12:01:07

"Fernando Cacciola" <fcacciola_at_[hidden]> wrote in message
news:002301c1e6f2$130a49c0$0f00a8c0_at_fernandoc...
> [...]
> Define a new class: shared_object, which fixes some of the possible
> semantics.

Yes.  That's essentially what my ref_counted class does.  In Peter's
terms, it specifies a base class with accessor functions, names the
accessor function add_ref (to be consistent with the interface of
shared_count from smart_ptr), sets the initial value to zero, and
does deletion in the pointer.

> Modify shared_ptr<T>  et.al. to automatically select between two
> implementations, one based on shared_object and the other as it
> is now (with a external count).
>
> The effect would be that *only* classes derived from shared_object
> would automatically make shared_ptr behave intrusively.

I thought about this for a little while, and really wanted to try it out,
but felt that A) I would have to add a policy template parameter to
shared_ptr, which some people would probably not like (even with
a default value); and B) it wasn't clear to me how to share the
commonality between shared_ptr and my intrusive_ptr elegantly, so
I didn't try (mostly laziness).  Anyway, the boost::smart_ptr
philosophy so far has been to create distinct types, rather than
parameterize on policies, so as a stop-gap measure, I decided to not
try to integrate it into shared_ptr or shared_array.  If someone a
bit more clever than me could do that, I'd be all for it, though.  Of
course, if we're going to make a full policy-based smart pointer,
why not just look at the strengths of both boost::smart_ptr and
Loki::SmartPtr, instead of cobbling it together in tiny pieces?

Dave