"Christopher Jefferson" <chris@bubblescope.net> wrote in message news:202EA587-0082-4DD3-A457-CD69710E6BBE@bubblescope.net...
On 25 Jan 2011, at 23:19, Domagoj Saric wrote:
"Christopher Jefferson" <chris@bubblescope.net> wrote in message news:C656C64C-8E00-4D67-ACE1-6A95B9A65281@bubblescope.net...
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 necessary...)
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 based access... -- "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