[Effective-cpp] Item 1: Uses and Abuses of vector

[Balog Pal]

> I still did not see any proof that end() is calculated or that it is
> actually cheaper to take end() out first.

For a general point, I observed optimizers can do better job if the
programmer extracts the common subexpressions. As the optimizer may or may
not discover them, or even  discovered, may not prove the expression will
yield the same result.

For the particular end() case, let's suppose it really just fetch a member
variable. Even that fetch can be slower than a direct access to a local
variable on stack or in a register.
OTOH, loop optimization is a special area in the optimizer, and a good one
will go lengths to find invariants, removing them from loops, on such one we
will see identical binary.
Locals are pretty well optimized, especially ones with trivial data flow --
so I can't see any chance to observe pessimized code. (creation of the local
will involve a cctor/dtor pair, but you get that back on the very first use
in the test. so that can't be an issue even if they were heawy ops, while we
expect no-ops there)

As I mentioned in my first post on this issue, I write loop headers a
certain way to express the intent, not for speed reasons.  Precalculated end
means the the container will be stable, call end() in the test means it will
change in some cases.   My personal meta-info. :)

> But I have seen broken code too
> many times, where end() was pre-evaluated and the vector (later) changed
> inside the loop.

Well, that happens when the tail swings the dog.

> I find it a bit frustrating that noone has addressed my
> question so far.

It looked like a rhetorical question.  No one would likely trade speed for
incorrectness. If iterators get invalidates inside the loop, you shall not
precalculate them.   But in those case just having the end() test is not
enoug either -- as you'll likely invalidate the running iterator as well.

> Since AFAIK end() is not necessarily calculated, as well
> as even if it is it is inline, I only see a disaster waiting to happen due
> to premature optimisation, and no benefit whatsoever.

Unless you expect the code to be literary -- and suggest the intent.   In
that case set-aside end mean stable vector, and not a means to gain some
cycles.

It's probably a good practice to make any kind of 'optimisaton' mandatory
to comment. Premature, postmature or any kind.  Then they will stand off.

> Can anyone show any measurements or any fact/proof that this optimization
is
> actually worth the risk of broken code?  So far I could only see opinions
> but not the facts they are based on.  I am not implying they aren't based
on
> facts, all I say is that those facts have either not been mentioned or I
> have managed to miss them.

IMHO that is a wrong approach to the problem, whatever the data would show.
Suppose two cases: A) showing big speed difference and B) showing no
difference.  Would that change your opinion on the issue?  If in your
environment people tend to screw up, will that be better to know in the rest
of cases they gain speed? Or if it turns out equal, will sticking to direct
end() calls remove *all* the related problems?