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 Pointee, class Access = weak_member_access<Pointee, &Pointee::weak_head> > class intrusive_weak_ptr { intrusive_weak_ptr *prev, *next; Pointee *ptr; public: typedef intrusive_ptr<Pointee, ...> 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