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
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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk