On 02/06/2016 08:33 AM, Bjorn Reese wrote:
On 02/04/2016 03:02 AM, Phil Bouchard wrote:
On the other hand I code completed the deterministic block_ptr in 2011 and I am wondering if there is anything I am missing to get it through the review process because this is one of the most important subject in computer science: https://svn.boost.org/svn/boost/sandbox/block_ptr/libs/smart_ptr/doc/index.h...
Do you have any performance measurements comparing block_ptr<T> with shared_ptr<T>?
We did some performance comparisons back in 2011 but I think block_ptr was using the worse case scenario here: http://lists.boost.org/Archives/boost/2011/05/182012.php But it's like comparing apples with oranges because shared_ptr is a smart pointer and block_ptr really is a memory manager there to replace the garbage collector. Also the ordered_malloc() it is using for the memory pool is far from optimal.
Btw, in the overview section you claim that shared_ptr<T> has to manage counters when it is dereferenced. I am not entirely sure that is correct.
Unless the counter is intrusive but that's the thing because block_ptr abstracts all of this and it is much less confusing to the end developer. And I'm not sure how intrusive counters can deal with multiple / virtual inheritance. The only time block_ptr might get confused is if you have a pointee object with multiple inheritance without virtual tables and you try to cast it to one of its parent. But I think the compiler should eventually label these strange cases.