[prev in list] [next in list] [prev in thread] [next in thread] 

List:       boost-users
Subject:    Re: [Boost-users] boost::weak_ptr and boost::intrusive_ptr
From:       "Nat Goodspeed" <ngoodspeed () solidworks ! com>
Date:       2006-12-01 19:13:00
Message-ID: 94F7A8DD4408D8499C6812FE42E2D4B7349DBD () corp-mail4 ! solidworks ! swk
[Download RAW message or body]

> -----Original Message-----
> From: boost-users-bounces@lists.boost.org [mailto:boost-users-
> bounces@lists.boost.org] On Behalf Of Sebastian Redl
> Sent: Friday, December 01, 2006 1:23 PM
> To: boost-users@lists.boost.org
> 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.)

[prev in list] [next in list] [prev in thread] [next in thread]