
On Oct 24, 2013, at 5:31 AM, Klaim - Joël Lamotte
On Thu, Oct 24, 2013 at 11:16 AM, Rob Stewart
wrote: Experience shows that having the implementation type as a parameter is rarely a good idea. Having a vector as implementation is far enough for me right now but I don't really care as long as the flat_* behaviour and performance are similar.
Is that general experience, or just yours? Both my experience and some I gathered online, so think more about my impression. That said, it's more about tradeof than just being a good or bad idea, I guess if there is a performance benefit to it and it don't make the implementation hard to follow, it would be a good idea.
Specializations, with different containers, would be different types, so interoperability adds complexity. Without concepts, BCCL should be used to ensure the container satisfies the interface requirements. That increases complexity, of course, and doesn't verify semantics. Still, that flexibility allows the use of std::array, shared memory containers, etc.
I'm not sure what a deque would enable in this case.
The same things deque offers over vector normally: VM-friendly allocations and growth at front and back without copying.
If one reserves enough space up front, there's benefit in vector. If allocating on demand, deque can be better.
I see, but it depends a lot on the allocation pattern, so having the choice would help fine tuning, which is your point if I understand correctly.
Right. ___ Rob (Sent from my portable computation engine)