On 03/13/2016 05:50 PM, Seth wrote:
To my surprise, though, in your tutorial I spot this https://github.com/philippeb8/block_ptr/blob/master/doc/tutorial.html#L113-L...
Secondly in the case where a cyclic set is being destroyed, in order to prevent block_ptr's member pointers from accessing an object that has already been destroyed the function cyclic() is provided to explicitly check the state of the pointee object
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. Worse, instead of "just leaking" resources, it looks like failure to do so leads to undefined behaviour.
Can you clarify this situation? Maybe I'm understanding this wrong.
I'm happy to have faced this special case back in 2011 because it is not obvious. So you have a cycle being wiped out by the proxy: +-> a1 ---> a2 -+ | | +---------------+ 1) a1.~A() will be called 2) a1.~A() will call a2.foo() 3) But a2 might have been wiped out already. So if you try to access a member in the destructor without explicitly checking if it was destroyed already then this will lead to an undefined behavior, just like dereferencing a null pointer. I could throw an exception when operator -> is used while a cycle is being destroyed but I don't think the overhead is worth it for this special case only.