Boost logo

Boost :

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

So you have a cycle being wiped out by the proxy:

+-> a1 ---> a2 -+
| |

1) a1.~A() will be called

2) a1.~A() will call

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at