Boost logo

Boost :

Subject: Re: [boost] [Block Pointer][Container] Works - Take 2
From: Phil Bouchard (philippeb8_at_[hidden])
Date: 2016-03-05 10:30:17

On 03/05/2016 05:30 AM, Peter Dimov wrote:
> Phil Bouchard wrote:
>> - I removed the usage of an allocator. Now there is no need for any
>> allocator anymore.
> I'm not sure I see how this would work. If you have
> void f()
> {
> vector<block_ptr<T>> v;
> }

You are close to a valid point. Although this case works:

If you have a cycle on the heap that is not owned by a root pointer from
the stack then I think the memory blocks will still be deleted.

If you look at how it is implemented, when the number of pointers from
the stack reaches 0 or if it is already 0 then all memory blocks will be
wiped out:

I thought there would be a leak there but thinking about it twice I
believe it should be fine. I'll try some other strange use case...

> block_ptr<vector<block_ptr<T>, block_allocator<T>>> v2;
> for the second case allows you to distinguish between the two.

Ideally I could do that but the implementation of the allocator for
containers turns out to be a real challenge.

The code is much cleaner "but" since it allocates more proxies, despite
using the fast pool allocator, that still slows down the overall

auto_ptr: 26164754 ns
shared_ptr: 27554248 ns
block_ptr: 144391600 ns

auto_ptr: 22210062 ns
shared_ptr: 46869206 ns
block_ptr: 138204822 ns

block_ptr<> is now 300% slower than shared_ptr<> for this type of benchmark.


Boost list run by bdawes at, gregod at, cpdaniel at, john at