Re: [boost] intrusive_ptr design question

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

On Mon, Jul 6, 2009 at 10:50 AM, Stewart, Robert<Robert.Stewart_at_[hidden]> wrote:
> Zachary Turner wrote:
>> That's correct.  The way I have envisioned is analagous to the
>> way shared_ptr allows you to specify a custom deleter.
>> Whenever a copy is made, the new copy gets the same deleter.
>> That way all copies agree on the deletion semantics.  As long
>> as all copies of the shared pointer that refer to the same
>> underlying instance of pointed-to object agree on reference
>> counting semantics, everything should be ok right?
>
> Deleting with the wrong deleter is an obvious failure which is likely to crash an application, but only happens once per object.  Manipulating a reference count, tens, hundreds, or more times, exposes a much greater danger.  Yes, copies will agree on how to manipulate the reference count, but the same memory can be referenced by separately constructed, non-copied smart pointer instances.
>

Could you elaborate a bit more?  I'm not sure I understand.  Of course
it's up to the programmer to specify correct reference counting
functions and construct shared_ptr instances correctly or else the
behavior will be undefined.  Are you saying that the problem would be
with something like this?

T* t = new T();

shared_ptr<T> ptr_t(t, multi_threaded_ref_counter());
shared_ptr<T> ptr_t2(t);

Causing the instance to be deleted twice eventually?  If so, how is
that different from:

T* t = new T();

shared_ptr<T> ptr_t(t);
shared_ptr<T> ptr_t2(t);

Or for that matter, from:

T* t = new T();

shared_ptr<T> ptr_t(t);
delete t;

Currently all copies of a shared_ptr agree on reference conting
strategy because they are all hardcoded to use
boost::detail::shared_count.  If they all use
foo::bar::mt_shared_count, or better yet if shared_count could be
parameterized with a template such as:

namespace boost { namespace detail {

template<class ref_counter>
class shared_count
{
};

where ref_counter is a class that provides a static interface guarantee such as:

struct ref_counter
{
   long add_ref();
   long release();
};

then there wouldn't even be any extra space overhead, since these
functions could be specified inline by the user.  With correct use of
default template arguments, shared_ptr could be modified to support
this while still allowing current syntax to select the existing shared
pointer ref counting scheme, making it backwards compatible.

If I misunderstood your statement though, please let me know.