Hi David, Why would it be a nightmare using std::vector? The allocation mechanism, for
the implementations I know, is not that bad, and one can always handle it pre-emptively, just as one would with "my_cool_buffer_array_like_thingie," especially with the kind of PODs one often deals with in high-performance operations. I just wonder if the problem you see with the allocation scheme is an algorithmic one or something specific to a certain implementation.
The 'problem' with std::vector, as with all the other containers, is that it treats memory allocation with little respect. This is precisely what my boost::monotonic proposal addresses. It gives you, the user of the containers, complete control over where the memory comes from, and how much there is of it.
Putting allocation strategies aside - as in a lot of high-performance cases one is well aware of the "max buffer size" - what factors do you see of std::vector that is intrinsically, or in current implementations, limiting performance?
Currently, all storage for a std::vector must be on the heap. That is not cool. It should also be able to come from the stack. That is what my proposal addresses. Having the ability to use STL containers which use stack-based memory is very important. It reduces memory fragmentation and increases cache coherency. Regards, Christian