Den 24-01-2011 00:59, Emil Dotchevski skrev:
On Sun, Jan 23, 2011 at 1:01 PM, Thorsten Ottosen<nesotto@cs.aau.dk> wrote:
As for the conjectured extra indirection, then I'm not sure it can become any major performance problem, nor do I see how one can avoid it when we need to go for the heap in certain cases.
Clearly the extra indirection is the only potential problem, otherwise a stack-based vector implementation could probably be replaced by a stack-based std::vector allocator.
clearly?
However, the cost of the extra indirection is platform-dependent and difficult to measure in the abstract. In my experience, most cases when someone has complained about inefficiencies in std::vector boil down to incorrect use:
- not using reserve(); - calling push_back()/insert() in a loop (which is inefficient even with reserve); - iterating by redundantly calling end() each time;
can be hoisted for vector, but not for most other containers.
- using operator[] for sequential access to the elements.
?
So the only meaningful way to evaluate the benefits of a std::vector alternative is to discuss specific use cases, considering other alternatives as well.
A stack-based allocator will work in C++0x, and probably works ok in C++03. In any case, the array needs to be created externally to the class which is somewhat more inconvenient, especially if you need to copy the vector around. But anyway, I agree on your requirements for a good analysis. -Thorsten