On Jun 9, 2009, at 9:48 PM, Christian Schladetsch wrote:
Hi Cory,
My largest complaint with C++ is that containers do not fit well with high-perf low-overhead scenarios, so I'm very interested in seeing something like this.
I would want to see it taken a step further though. Overhead can be a big deal for large objects, so re-implementing string and vector completely (so that you don't have the pointer/capacity specified twice, in container & allocator) would be a welcome change.
I don't think anyone doing high-performance code uses std::string.
I have; when there has been no need to add to it - obviously - or deal with Unicode.
It is a nightmare, and similarly for std::vector, for the reasons you claim.
I have... 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. 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? /David