Re: [boost] shared_ptr/ intrusive_ptr

From: Phil Nash (phil.nash.lists_at_[hidden])
Date: 2002-06-25 12:06:22

Hi Peter (et al), thanks for the response,

> > (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? :-)

Nothing major, just that, as counted_base seems to have been promoted out of
detail it seems odd to have to include detail/shared_count.hpp to get to it.

> > 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.)

Ok... this was how I tried it initially but I had other problems - in
particular in the taking weak_ptrs in the constructor of the object being
ref-counted... maybe that is not possible after all - you didn't answer that
bit before.

> intrusive_ptr will increase the reference count in its constructor.

Yes...

> [...]
>
> > 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.

Ok, I see what you are saying, but doesn't that defeat the point of
weak_ptr's in the case of intrusive counts? I can seem why it needs to be
that way now you have pointed out to me what should have been obvious
(doh!), but I'm sure I'm still missing something here. Is what I have just
said true - that you can't use weak_ptrs with objects derived from
counted_base (well, you can, but the weak_ptr's are no longer weak)?
If so is there a way round this - such as detaching the weak_count into a
seperate object from use_count?
Please tell me I have missed something else obvious and I can do it after
all :-)

Many thanks,

[)o
IhIL..