Re: [Boost-users] boost::weak_ptr and boost::intrusive_ptr

From: Nat Goodspeed (ngoodspeed_at_[hidden])
Date: 2006-12-01 14:13:00

> -----Original Message-----
> From: boost-users-bounces_at_[hidden] [mailto:boost-users-
> bounces_at_[hidden]] On Behalf Of Sebastian Redl
> Sent: Friday, December 01, 2006 1:23 PM
> To: boost-users_at_[hidden]
> Subject: Re: [Boost-users] boost::weak_ptr and boost::intrusive_ptr
> 
> The use case here is this:
> 
> NodePtr base = make_tree();
> NodePtr child = base.get("path/to/child");
> base.reset();
> Now, unless the parent knows that it owns the child and notifies it,
the
> parent pointer of child is dangling. A weak pointer can detect this
> situation.

[Nat] Okay.
 
> The reason I see for there being no weak_intrusive_ptr is that it is
> quite simply impossible to implement while staying intrusive. Let's
> remember what a weak pointer does: after the death of the object it
> points to, it knows that it is now invalid. There being no
notification
> of pointers when other pointers get destructed, there's only one way
to
> do this: to keep the refcount for the object alive, so that the weak
> pointer can check it.
> But if the refcount is part of the object, as is the case for
> intrusive_ptr, it's impossible to keep the refcount alive while
> destroying the object.
> 
> In other words, the appeal of intrusive_ptr is that it doesn't require
> any resources outside the object it points to. However, this
restriction
> makes it impossible to implement an efficient weak pointer.

[Nat] Not to be argumentative, but...

It seems possible to implement weak_ptr notification by building a list
of weak_ptr instances referencing a given object. If we don't want that
list to consume additional heap memory, the list could itself be
intrusive in the weak_ptr objects. If we want it to be efficient, we
build a doubly-linked list. (This may call for a policy-based
implementation so the consumer can decide which overhead is least
noxious.)