|
Boost : |
From: David Abrahams (dave_at_[hidden])
Date: 2002-10-01 09:43:11
From: "Peter Dimov" <pdimov_at_[hidden]>
>
> If you test the weak_ptr, you'll see that it will properly report that
it's
> expired(); use_count() will be zero; and if you try to construct a
> shared_ptr from it, the construction will fail.
>
> > But when I am using weak_ptr with intrusive_ptr it know works like
normal
> > pointer?
> >
> > I think I missed something. Is it bug or feature?
>
> It is a "feature". The reference count is contained in counted_base, and
> it's embedded into the object. It is not possible to destroy the object
> without also destroying the counted_base, and this cannot happen while
there
> are still weak pointers to that counted_base. That's why
> counted_base::dispose() is invoked when the last shared_ptr is destroyed,
to
> let you release the resources contained in your object.
I don't know how long I'll be able to hold this position in the face of
move semantics, but so far I've been successful at promoting the idea that
a "destructible but otherwise unusable" state is misguided for most
classes. One thing I don't like about this arrangement is that is tends to
encourage that sort of design. I think it might be avoidable by having the
user inherit from something like this:
struct intrusive_count
{
intrusive_count() : count(new counted_base) {}
~intrusive_count() { if (count->weak_count == 0) delete count; }
counted_base* count;
};
Just a thought.
-----------------------------------------------------------
David Abrahams * Boost Consulting
dave_at_[hidden] * http://www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk