Subject: Re: [boost] Stack-based vector container
From: Domagoj Saric (dsaritz_at_[hidden])
Date: 2011-01-30 11:53:04
"Christopher Jefferson" <chris_at_[hidden]> wrote in message
> On 25 Jan 2011, at 23:19, Domagoj Saric wrote:
>> "Christopher Jefferson" <chris_at_[hidden]> wrote in message
>>> I find most modern compilers do not have issues with calling end()
>>> repeatedly, or push_back().
>> push_back() is a possibly-new-calling/possibly-throwing 'fat function',
>> in which way do you mean that modern compilers 'do not have issues' with
>> it? And could you please name such a compiler...
> for vector<int>::push_back, gcc will inline the common case (there is no
> need to allocate new memory) and no inline the memory allocation when the
> vector grows. Therefore you just end up paying for one comparison of two
> pointers for each push_back call, to check there is still space.
But the code for the branch that allocates memory and is never executed (for
known fixed sized problems/usages) still gets generated and causes EH code
to be generated for all calling code...
Plus the inlining causes template bloat...
(When, again, adding a constant/integer to a pointer is all that is
>> You know of a (real) use case where indexed based access is faster than
>> pointer based?
> I have found in the past, depending on the compiler and it's settings, it
> can be unpredictable. I don't have exact numbers, but there were points in
> the past where gcc's loop unroller unrolled some index based code, but not
> pointer based code. They may well have fixed it now.
Oh...that's a compiler issue, not something intrinsic to index-vs-pointer
-- "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