Seth wrote:
To me it looks like this comprehensively refutes the purpose of the block_ptr as a ref-cycle mitigation scheme: the programmer seems to still be responsible for anticipating cycles and special casing destructors for it.
This problem can't be solved in general. When you have struct node { node_ptr<node> p_; ~node() { p_->something(); } void something(); }; and you have a cycle with two nodes pointing at each other, it's simply not possible to destroy them properly. The shared_ptr collectors with which I have experimented try to sidestep this by first zeroing all pointers that participate in a cycle, then running the destructors. So you'd need ~node() { if( p_ ) p_->something(); } See for example http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2232.html#cycles I abandoned this proposal because I could think of no way to make it work with multiple threads and weak_ptr.