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,
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: 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-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. Seth