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

[White Wolf]

effective-cpp-bounces at accu.org wrote:
>> 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.

OK.

> For the particular end() case, let's suppose it really just
> fetch a member variable.

Actually I think it does on most implementations.

> Even that fetch can be slower than a
> direct access to a local variable on stack or in a register.

Can.  The real question is however: is it?  Remember the rules of
optimization!

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

I can.  If accessing the local is the same cost as accesing end(), your code
is longer with that very assignment to the local.  And in addition more
fragile.

> (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)

And that too, although most vector iterators today are plain wrappers for a
pointer.

> 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. :)

My problem with this approach is that it only works in the ideal case.  The
expression "My personal" does not exist in large teams or large
organizations.

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

Wag the dog.  I don't think so.  It happens, when unexperienced people write
C++ code, or touch existing C++ code.  Which means it happens every day.

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

Well, sorry for that.  All my weapons in asking a question are the question
mark and explaining why I ask. :-)  That is how much my English can do.

> No one would likely
> trade speed for incorrectness. If iterators get invalidates
> inside the loop, you shall not
> precalculate them.

When?  Where I work a code-base is usually used for 10+ years.

> But in those case just having the end() test is
> not enoug either -- as you'll likely invalidate the running iterator
> as well. 

Not necessarily.

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

That may be true for you, but I do not think it is a convention yet.
Therefore I would not do it in my code.  Anyway I was asking about the
optimization since that was the suggested reason in the original email.  I
can understand that you use it for a different purpose.

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

Actually anything which is not conventional/idiomatic or obvious should be
commented.  Or people reading code should really read the code and think.
The former seems to be easier to achieve. :-)

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

Yes.

> If in your environment people tend to screw up, will
> that be better to know in the rest of cases they gain speed?

If doing so gains speed than it is worth to teach people when to do so and
when not.  So that they will not screw up.  If it does not or rarely does,
then it is much-much easier to just teach the idiomatic form with no
pre-fetched end().

> Or if it turns out equal, will sticking to direct
> end() calls remove *all* the related problems?

I cannot see how that question is relevant.

Attila