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:
> 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:

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

> 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, gregod at, cpdaniel at, john at