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 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk