Re: [boost] shared_ptr/ intrusive_ptr

From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-06-25 09:50:42

From: "Phil Nash" <phil.nash.lists_at_[hidden]>
>
> The problem I have is that what I have read of the thread on intrusive_ptr
> and associated mods in shared_ptr led me to believe that I should be able
to
> provide intrusive ref counting semantics to a class in a manner that is
> interoperable with shared_ptr by deriving my class from
boost::counted_base

Correct.

> (btw, I see that counted_base has moved out of the detail namespace, but
is
> still located in shared_count.hpp which is in the detail sub directory. Is
> this a contradiction or is that intended?).

What is the difference? :-)

> This at first seems to be correct and compiles ok, and even begins to run
> ok. I see that constructing an intrusive_ptr from a pointer to an object
> derived from boost::counted_base uses the objects counted_base for its ref
> counting, and I can subsequently construct a shared_ptr to the object from
> the intrusive_ptr and it continues to use the object's counted_base rather
> than creating its own.
> However, to get this far I have to construct the counted_base with an
> initial use_count (and weak_count) of 1.

No, you need to construct the counted_base with initial counts of zero
(there is a default constructor present.)

intrusive_ptr will increase the reference count in its constructor.

[...]

> Now I have a different problem. I have provided an override for the
> dispose() virtual function from counted_base so that I delete myself when
> the use_count gets to zero. That works ok, but counted_base also wants to
> delete itself when the weak_count reaches zero. This is fine when
> counted_base is the base of a different object, but we don't need (or
want)
> two deleters for the same object!

Sorry, you can't do that. The counted_base must stay alive if there are
pointers to it, shared or weak; you must not 'delete this' in dispose(). You
should release any resources that are managed by your object, but keep it
alive. If you kill the counted_base, the weak pointers will try to decrement
a non-existent weak count, and crash.