
On Oct 25, 2013, at 3:49 PM, Klaim - Joël Lamotte
On Fri, Oct 25, 2013 at 9:44 PM, Rob Stewart
wrote: On Oct 25, 2013, at 2:00 PM, Nevin Liber
wrote: On 24 October 2013 17:10, Rob Stewart
wrote: I meant that stack allocated memory could be used if std::array's interface satisfies the needs of flat_*. std::array can be one choice among many.
I'm not seeing how a container of exactly N elements would be useful as a backing store for flat_xxx. Could you show an example?
I was just thinking of a use case in which a map is needed, but memory is constrained or preallocated. I was also just showing how permitting user-specified containers opens possibilities.
A flat_map, backed by std::array, is quite possibly no faster than a normal C++11 map, with a suitable allocator. A C++03 map won't use its allocator for nodes, but IIRC, a C++11 map will.
But then it would make the flat_map semantic changes because it have runtime-fixed-size and it makes it not inter-changeable, wouldn't it? That being said it would be the same as to have a pool allocator I guess.
The semantics would be the same: std::bad_alloc when memory is exhausted. The difference is that one gets a prescribed amount of memory a priori and the other can try to use all available application memory. ___ Rob (Sent from my portable computation engine)