Boost logo

Boost :

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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk