Is there any basis for this alternative 'for' loop syntax?

You are right about optimizing compilers and prefix vs. postfix ++ operator. It does not matter for an int, but it matters more when you use iterators.

The second portion of your question is more interesting:

Using != instead of < is also suspicious to me, because it makes the loop semantically different than the original version, and can lead to some rare, but interesting, bugs.

I would rephrase it as "can catch some rare, but interesting, bugs."

One simple way to argue this point was offered by Dijkstra in his book A Discipline of Programming. He pointed out that it is easier to reason about loops with stronger post-conditions than it is to reason about loops with weaker post-conditions. Since post-condition of a loop is the inverse of its continuation condition, one should prefer loops with weaker continuation conditions.

a != b is weaker than a < b, because a < b implies that a != b, but a != b does not imply that a < b. Therefore, a != b makes a better continuation condition.

In very simple terms, you know that a == b immediately after the loop with a != b is over; on the other hand, when the loop with a < b is over, all you know is that a >= b, which is not as good as knowing the exact equality.

I personally don't like the second one, I would use:

for (int i = 0; i < n; ++i); //A combination of the two :) 

int i = 0 vs int i(0)

No difference whatsoever, they even compile to the same assembly instructions (no optimizations):

int main() { int i = 0; //int i(0); } 

int i = 0 version:

main: pushq %rbp movq %rsp, %rbp movl $0, -4(%rbp) movl $0, %eax popq %rbp ret 

int i(0) version:

main: pushq %rbp movq %rsp, %rbp movl $0, -4(%rbp) movl $0, %eax popq %rbp ret 

i < n vs i != n

You are right that the != might introduce some interesting bugs:

for (int i = 0; i != 3; ++i) { if (i == 2) i += 2; //Oops, infinite loop //... } 

The != comparison is mostly used for iterators, which don't define a < (or >) operator. Maybe that's what the author meant?

But here, the second version is clearly better, as it more clearly states intent than the other one (and introduces less bugs).

i++ vs ++i

For built-in types (and other trivial types), such as int, there is no difference, as the compiler will optimize the temporary return values out. Here, again, some iterators are expensive, and so the creation and destruction might be a performance hit.

But that really doesn't matter in this case, as even without optimizations they emit the same assembly output!

int main() { int i = 0; i++; //++i; } 

i++ version:

main: pushq %rbp movq %rsp, %rbp movl $0, -4(%rbp) addl $1, -4(%rbp) movl $0, %eax popq %rbp ret 

++i version:

main: pushq %rbp movq %rsp, %rbp movl $0, -4(%rbp) addl $1, -4(%rbp) movl $0, %eax popq %rbp ret 

The two forms are in no way related to performance. What matters is how you write code in general. Follow similar patterns and focus on expressiveness and conciseness. So for the initialisation, prefer int i(0) (or better: i{0}) as this underlines that this is an initialisation, not an assignment. For the comparison, the difference between != and < is that you put lower requirements on your type. For integers there is no difference, but in general iterators might not support less than, but should always support equality. Finally, prefix increment expresses your intent better because you do not use the result.

In this code it makes no difference. But I guess what the writer is aiming for is to use the same style coding style for all of the for loops (except range-based ones, presumably).

For example if we had some other class as the loop counter type

for ( Bla b = 0; b < n; b++ ) 

then there are problems:

• Bla b = 0; may fail to compile if Bla does not have an accessible copy/move constructor
• b < n may fail to compile if Bla does not admit definiig a weak ordering, or define operator<.
• b++ may fail to compile or have unintended side-effects, since post-increment typically returns by value

Using the writer's suggested pattern, the requirements on a loop iterator are lessened.

Note that this discussion can go on forever. We could say int i{}; is better because some types might not admit 0 as initializer. Then we could say, well what if n was not an int? It should really be decltype(n) i{}. Or in fact we should use a range-based loop which fixes all the above problems. And so on.

So at the end of the day it is still personal preference.

i != n

Frankly, slide 8 lost me right there, and you are correct with the suspicion that something might not be quite right.

Aside from the high likelyhood that a modern compiler will have those kinds of loop optimized as thoroughly as it is theoretically possible for current CPUs, encouraging a programmer to write less robust code to "help the optimizer" for whatever reason is just very oldfashioned and has no place at all in the modern world, IMO. The real cost of software is the human time these days, not the CPU time, for 99.99...% of all projects.

On a meta-level, truisms have no place in coding guidelines. A slide establishing a coding convention without giving objective and well-thought-out reasons for it is useless. Note that I would be OK with a reason like "we do it this way because we want to pick one style instead of a plethora", I don't need a technical reason - just any reason. I can then decide whether I accept the reasoning behind the coding guideline or not (and thus accept the guideline itself).

It is stylistically better to use postfix increment/decrement in C-style for loops whenever this is possible,

for (i = 0; i < n; i++) 

rather than

for (i = 0; i < n; ++i) 

With a postfix operator, the loop variable i appears on the left-hand side of all three expressions, which makes the code easier to read. Also, if you need to step by any value other than 1, you have to write it with the i on the left ...

for (i = 0; i < n; i += 2) 

so for consistency's sake it should also be done that way when you are using the ++ shorthand for += 1. (As pointed out in the comments, we might find it easier to read += 1 than ++ if we didn't have 45 years of convention teaching us ++.)

With fundamental types like int, prefix/postfix increment will make no performance difference; as other answers have demonstrated, the compiler will generate exactly the same code either way. With iterators, the optimizer has to do more work to get it right, but I don't think there's any excuse for a C++11-era compiler that fails to handle postfix operator++ as efficiently as prefix operator++ when they are used solely for their side effects.

(Of course, if you're stuck with an iterator that only supports prefix ++, then you write it that way.)