Just a small question: Isn't it so, that linked lists (double or single), can be spreaded in the memory, so that cache misses and page faults are subject to happen? I think deque is a better choice (which can be better optimized in terms of locality)... With Kind Regards, Ovanes Markarian On Fri, December 1, 2006 20:13, Nat Goodspeed wrote:
-----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.) _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users