Re: [boost] intrusive_ptr design question

Subject: Re: [boost] intrusive_ptr design question
From: Zachary Turner (divisortheory_at_[hidden])
Date: 2009-07-06 16:00:20

On Mon, Jul 6, 2009 at 2:31 PM, Stewart, Robert <Robert.Stewart_at_[hidden]>wrote:

> You could supply an object with such a pair of functions on it that counter
> can call.  By grouping the functions in a UDT, you eliminate the chance of
> incorrect pairing and increase the chance of optimization.
>
> OTOH, if you embed the reference counting behavior into the type of the
> smart pointer -- counter<int, safe_ref_counter>, for example -- you reduce
> the opportunities of different parts of the code using different reference
> counting behavior for the same memory.  The compiler can catch cases of
> misuse.  Furthermore, the policy class groups the function pair in one type,
> thus eliminating the chance to combine them incorrectly.
>
> Boost.SmartPtr currently traffics in counter<int> types (shared_ptr<T>,
> intrusive_ptr<T>, etc.) and not in counter<int,policy> types, thus safe
> usage of your idea cannot be added to those types and must be done with a
> policy class in a new smart pointer type.
>

Thanks for the clarification.  I think we basically agree in that case.  My
original proposal didn't mention anything about a ref counting policy, but I
kind of arrived at the conclusion that that was the best way to do it anyway
(see towards the end of my previous post).

Making major interface changes to existing libraries is always inherently
risky but is there any reason that adding a policy to shared_ptr, with a
default policy template argument that uses the existing ref counting
strategy, would be bad?  I can't think of any scenarios that this would
break existing code, except maybe if someone was using a shared_ptr to
parameterize a class that was expecting a template template parameter, and
this seems pretty unlikely.

It seems that it would be easier to do this than to design yet another smart
pointer class, which would then have to work correctly in the presence of
all the other multitude of smart pointer classes.

In theory, intrusive_ptr and weak_ptr could then even become special cases
of shared_ptr by having boost supply policies implementing weak_ptr /
intrusive_ptr reference semantics.  Note that I haven't actually thought
about that aspect in tremendous detail, but it seems like it could be made
to work.  Even the requirement of intrusive_ptr to have the same memory
footprint of a raw pointer should be do-able if it doesn't instantiate the
policy class as a member of the smart pointer.