Re: [boost] [block_ptr] Request for a review manager

Subject: Re: [boost] [block_ptr] Request for a review manager
From: Phil Bouchard (philippeb8_at_[hidden])
Date: 2016-02-06 16:05:01

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