Loop condition: why "not-equal" instead of "lower-than"

Question

I was assigned to work on an Android-Java (real-time game) project with a considerable (partially legacy) code base.

Most of the loops I see are like this (where mjk is usually a Java array):

    int count = mjk.length;
    for (int i = 0; i != count; ++i) {
        // Stuff dealing with mjk[i]
    }

I generally write loops such as this:

    int count = mjk.length;
    for (int i = 0; i < count; i++) {
        // Stuff dealing with mjk[i]
    }

Any idea why the original author (whom I've been unable to contact so far) used the previous form? Is it common in C++?

The practical reason I ask this is JIT optimization: as far as I know, Android optimizes loops (induction variables, invariants, range check migration to loop prologue etc.), and I wonder if the non-equal may prevent such optimizations (unlike lower-than, which specifies a well-defined range).

I'm merely curious if the first usage has any advantages/disadvantages over the second one (in all respects).

Answer 1

The second form has one clear advantage: if you for some mistake manipulate i inside the loop, the first form will probably crash if i get's assigned to a value greater than mjk.length and the second form will simply ends the loop.

The only single advantage I can see in the second approach is that "!=" might run faster than "<" but I'm not even sure this happens at all (this might depend on the JVM implementation and the hardware itself.) But please notice that if you do something substancial inside the loop the difference will not be noticed at all since it's executed only once per iteration.

I would definitely use the second one cause it's much safer.

Answer 2

I believe that this was just an inexperienced programmer. In general, it's of course always better to use a < for more robustness. In the case of fooling around with the index (e.g. by changing the step interval to i+=2), it will not produce an infinite loop.

Technically, comparison might use less CPU time (not so familiar with this though), but the effect is marginal or just irrelevant, it will not destroy any program's performance... :)