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