Re: [boost] intrusive_ptr design question

Subject: Re: [boost] intrusive_ptr design question
From: Daniel Hulme (st_at_[hidden])
Date: 2009-07-06 03:04:18

On Sun, Jul 05, 2009 at 07:58:49PM -0500, Zachary Turner wrote:
> I was wondering from a design perspective, why was it decided that
> intrusive_ptr should rely on user-defined free functions
> intrusive_ptr_add_ref and intrusive_ptr_release to handle the
> reference counting?

One of the main reasons for intrusive_ptr is to have smart pointers to
third-party classes that already have their own refcount. Since you
can't add a member to a class you don't control, using member functions
to manipulate the refcount would rule out that use. The expectation in
this case would be that the user would write these two free functions to
just call the appropriate member functions on the third-party class.

> This makes it somewhat inconvenient, for some
> constant type T, to support having two different instances of
> intrusive_ptr<T>, each of which use a different reference counting
> strategy.
> 
> If there's a clever way to allow this that I'm missing please advise.

I must admit, I'm not really sure what you are trying to achieve. It
sounds like you have some instances of T, and you want some of them to
store their reference count in some way, and the rest to have a
completely unrelated way of storing their reference count. But if this
is the case, it sounds like you actually have two different types, and
Scott's solution sounds right; and even so, I don't know what you hope
to achieve by that.

-- 
"It must be accepted as a principle that the rifle,  effective as it is,
cannot  replace  the effect  produced  by the  speed of  the horse,  the
magnetism of the charge, and the terror of cold steel."
  -- British Cavalry training manual, 1907 ::: http://surreal.istic.org/