"David Bergman" <David.Bergman@bergmangupta.com> wrote in message news:FF46F967-E45E-4188-9976-6090F2054A51@bergmangupta.com...
What you are doing here is to mix two (presumably...) orthogonal aspects, in that you bake in the allocation policy in the vector interface.
In fact, a "static allocator" to be used in cases like std::vector was discussed at length on this list a year ago (or was it two years?)
This is not quite the same, i.e. std::vector is 'too' generic so it would still incur overhead compared to a simple "stack-buffer-with-an-end-pointer": it contains (and maintains) three pointers (or std::size_ts) begin, end and "reserved end" as opposed to only an end pointer/std::size_t + it is designed around the 'idea' of "fallible allocation", that is it expects allocation requests to possibly throw so in some cases/member functions implementations have to use guard objects and/or explicit exception handling (which the optimizer may or may not be able to remove) ... and this same problem might obfuscate the code (for the compiler) enough so that the optimizer might not be able to detect that a 'std::vector with a static allocator' does not throw and cause it to still emit EH code/unwind funclets (for surrounding/calling code)... -- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman