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