$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
Subject: Re: [boost] [pool2] Requests for comment
From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2012-10-16 16:02:28
El 16/10/2012 15:06, Klaim - Joël Lamotte escribió:
> Stable vector don't guarantee contiguity but it apparently does keep bloc
> of objects contiguous as much as it can.
> If you reserve your optionals at first, then a lot of contiguous memory is
> allocated for your future objects, which is basically a pool.
> I'd say the main difference with boost::pool for example is that you can't
> have any input on the memory blocks boost::stable_vector will allocate.
stable_vector allocs nodes even when just reserving (and of course when 
resizing). It keeps then in an internal pool as it offers better 
exception guarantees than vector: it does not throw a memory error 
exception (as memory was already reserved) and of course, it does not 
have potentially throwing move operations when inserting in the middle.
> I might be wrong on the boost::stable_vector behaviour but my current tests
> shows that it's a win win scenario in my case.
If you reserve, then stable vector will call the allocator several times 
to reserve memory and fill the internal pool. That memory is probably 
contiguous (it depends on the allocator).
In the near future I hope to improve the performance of stable_vector 
and other node containers adding "burst-allocation" extensions to a 
general purpose heap allocator, an improved version of:
http://www.drivehq.com/web/igaztanaga/allocplus/#Chapter2
Current experiments are very encouraging.
Ion