Re: [boost] Stack-based vector container

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

"Emil Dotchevski" <emildotchevski_at_[hidden]> wrote in message 
news:AANLkTinASY3YpYfbXHFhjT44gtO2_1Zs=-nJTo1xhzoU_at_mail.gmail.com...
> The performance benefits remain theoretical until measured

In this context this is as meaningful as saying that the performance 
benefits of std::vector<>::reserve() remain theoretical until measured...

...or that the assertion that the performance benefits remain theoretical 
until measured itself remains theoretical until proven...

No measurement is required to know that an 'unchecked'+'uninitialised' 
resize() function compiles down to a single CISC instruction (adding a 
constant to a pointer) while its 
'checked'-possibly-to-heap-expanding-thus-possibly-throwing version compiles 
to a 'full fat' function that 'pollutes' the caller with EH code/unwind 
funclets (plus in practice disables certain compiler optimizations)...
The fact that this may have little or no consequence on your code or you 
simply do not care is just as simply irrelevant (because, of course, C++ is 
still not a 'managed' language and one size does not fit all)...

How about, for once, we turn the (mis/ab)used 'root of all evil' rule on its 
head and disallow premature pessimization until measured and proven 
'negligible'...

> and, in
> theory, a "stack-based" vector is not needed because std::vector is
> allowed to be stack-based when possible.

As already explained a std::vector<> with a stack/static based allocator is 
not quite equivalent to the original proposal...

-- 
"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