Boost logo

Boost :

Subject: Re: [boost] Stack-based vector container
From: Domagoj Saric (dsaritz_at_[hidden])
Date: 2011-01-25 16:45:57

"Emil Dotchevski" <emildotchevski_at_[hidden]> wrote in message
> On Sat, Jan 22, 2011 at 11:13 PM, Stephan T. Lavavej
> <stl_at_[hidden]> 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 

Boost list run by bdawes at, gregod at, cpdaniel at, john at