Nat Goodspeed wrote:
[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.)
So basically, within the referenced object, you have a pointer to the
first weak pointer, which holds a pointer to the next weak pointer, and
so on, linked in both directions?
Interesting idea. I can't find any problems with it.
template >
class intrusive_weak_ptr
{
intrusive_weak_ptr *prev, *next;
Pointee *ptr;
public:
typedef intrusive_ptr strong_ptr;
intrusive_weak_ptr(const strong_ptr &o)
: prev(0), ptr(o.get())
{
intrusive_weak_ptr * head = Access::get_head(*o);
head->prev = this;
next = head;
Access::set_head(*o, this);
}
strong_ptr lock()
{
if(!ptr) {
throw lock_error();
}
return strong_ptr(ptr);
}
void signal_destruction()
{
ptr = 0;
if(next) {
next->signal_destruction();
}
next = 0;
prev = 0;
}
};
With the destructor of intrusive_ptr starting the signal_destruction
chain, of course.
Some TMP would be required to make intrusive_ptr only require weak_ptr
if it's actually used.
intrusive_list could be used to make the weak_ptr list more robust.
Sebastian
