Re: [boost] [Block Pointer] Question about cycles rationale

Subject: Re: [boost] [Block Pointer] Question about cycles rationale
From: Phil Bouchard (philippeb8_at_[hidden])
Date: 2016-03-13 18:36:49

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-L114
>
>> 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.