Re: [boost] intrusive_ptr design question

Subject: Re: [boost] intrusive_ptr design question
From: Neil Groves (neil_at_[hidden])
Date: 2009-07-08 15:33:50

On Wed, Jul 8, 2009 at 8:21 PM, Ulrich Eckhardt <doomster_at_[hidden]> wrote:

> On Monday 06 July 2009 17:23:41 Zachary Turner wrote:
> > Is there a case to be made for a more flexible shared_ptr (either
> > through modification or through a new class addition) that allows
> > one to provide custom reference counting semantics much the same way
> > that shared_ptr allows one to provide custom deletion semantics?
>
>
> Maybe it's already there: shared_ptr doesn't care if the passed deleter
> actually deletes anything. If you now take an object with an existing
> reference count, you just increment that count and pass the function that
> decrements it as deleter function to a shared_ptr constructor. This creates
> a
> parallel reference count, but it should be safe. Nothing can pull the
> object
> from under the shared_ptr's feet because it holds a reference. The
> shared_ptr
> doesn't destroy the object either, at most it decrements the reference
> count.
>

It isn't already there, because unfortunately, in general, this doesn't
work. You need the reference count to increase when the shared pointer is
copied, for example. I am of the opinion that this isn't a problem we should
solve. Inherently mixing lifetime idioms on a single object instance is
dangerous. Interoperation with shared_ptr does not make semantic sense. The
only working scenario I can imagine is one where the shared_ptr would behave
exactly like the intrusive_ptr. As others have indicated this would increase
the memory footprint of shared_ptr since any customisable functor for the
reference count increment / decrement would need to a have a reference to
the count.

Hence I have yet to see a convincing case where the design of such
interoperation would be the optimal design, and the implementation overhead
does not obey the zero overhead principle.

> Uli
>

Regards,
Neil Groves