"Emil Dotchevski" <emildotchevski@gmail.com> wrote in message news:AANLkTin5gq+-zYpW+z9+xGBNW25nvqJOpRJJv484phGJ@mail.gmail.com...
On Sat, Jan 22, 2011 at 11:13 PM, Stephan T. Lavavej <stl@exchange.microsoft.com> wrote:
The As If Rule always applies, but I can confidently say that nobody's compiler and Standard Library implementation conspires in such a way.
Right, so it remains theoretical.
My point was that the benefits of a stack-based vector type are also theoretical.
So, if I got this right, you managed to sort-of-prove that a stack-based partial/nonstd::vector<> implementation is theoretically possible...what I fail to see is how does this, in any way, through analogy or otherwise, implies anything about the benefits of a stack-based vector...much less about the original or other proposals so far listed in this thread...
Practically speaking, if std::vector is causing performance problems, I don't see myself thinking "ok, I need a stack-based vector." In that case, it makes more sense to me to throw all abstraction out and get down to the metal.
As one size does not fit all, 'I don't see myself' is not a valid argument of any kind...By your rationale you not only do not need/want a stack-based vector/array-like container (which was proposed here precisely because there are people that demonstrably need it) but for example also intrusive_ptrs (after all if shared_ptr is somehow causing performance problems we should 'get down to the metal'/raw pointers)...should we have those removed from Boost? If not, what is the issue with including a new container in Boost that tries to solve a specific problem and that noone will force you to use? -- "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