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

Subject: Re: [boost] [Block Pointer] Question about cycles rationale
From: Seth (bugs_at_[hidden])
Date: 2016-03-13 17:50:11

Phil,

[I'm sorry, I can't seems to find the root of this thread (I might have
deleted it).]

I've been reading the documentation, especially presentation (PPT),
rationale + tutorials.

In the presentation/rationale you state that a downside of refcounted
pointers is responsibility to manually break cycles (the samples quote
using weak_ptr to do it). In contrast you state that block_ptr doesn't
require cycle tracking; e.g. in the rationale:

> Thus whether the /set/ was composed of memory blocks referencing each
other in a cyclic way or not, all of them will be subject to destruction
and deallocation indifferent from the cyclicism problem presented by the
reference counters. As we can see in the following example,
the /set/ counter reaches 0 and consequently every elements composing
the /set/ will be destructed and deallocated:

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.

Seth