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
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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk