0

Obviously, 

for ( int i = 0; i != n; ++i )

works just the same as 

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

But is it normal for a developer to feel uneasy about the former? I'm always afraid that some freak accident will make the i in the former loop "miss" the n. Whereas, in the second loop, if i somehow stops incrementing correctly then the < operator will act as a barrier.

This made me think today about the question of which is actually more possible to fail given the full spectrum of freak accidents. Someone here with a knowledge of compiler/hardware stuff might have an answer for me.

Subpar Web Dev
  • 3,210
  • 7
  • 21
  • 35
  • 18
    If you have a hardware failure, the workings of a `for` loop are probably the least of your worries. – Wai Ha Lee Dec 04 '15 at 16:43
  • 1
    If you have bits flipping in your processor's internal registers then you have bigger problems. – chillitom Dec 04 '15 at 16:44
  • 2
    I think the use of `<` over `!=` winds up being more of semantics than safety: what you really want to do is iterate the block while `i < n`, which immediately gets mentally translated to "do it `n` times." Seeing `i != n` winds up looking more like some strange situation in the code could make `i` jump over `n` and then come back or something. The `<` is easier to read and comprehend, and makes intentions clear. – eouw0o83hf Dec 04 '15 at 16:45
  • 2
    *But is it normal for a developer to feel uneasy about the former?* It's not normal for developers to worry about hardware failures affecting the behaviour of the CPU and RAM at all. Maybe disk drives and other electro-mechanical devices. On the other hand, on one of the largest supercomputers, with `O(10^6)` processor cores, failure of a single core during execution is a real concern. Dang it, now I *am* worried. – High Performance Mark Dec 04 '15 at 16:46
  • You probably need to specify that n >= 0. Otherwise the first loop will never terminate even when the hardware is working just fine :-) –  Dec 04 '15 at 16:46
  • If a "freak accident" could change `i`, it could also change `n`. – David Arno Dec 04 '15 at 16:46
  • @eouw0o83hf apart from safety when the loop increments `i` above `n` and gets stuck looping "infinently" – TheLethalCoder Dec 04 '15 at 16:47
  • Thousands of programs use the standard library's iterators, where you typically loop using `!=`. If by some incredible miracle there's a hardware problem, chances are your program will not be the first one to break. – Joel Dec 04 '15 at 16:47
  • Just assuming that (due to some **really** strange error) exactly this happens. You'll have a lot more severe problems than that simple for-loop. The only way i think of this could happen would be either a corrupted executable or a **heavily** damaged processor. The corrupted executable would most likely cause way more severe damage than a for-loop that doesn't terminate, with a damaged processor you'd most likely not even notice, since the PC already crashed before you even accessed the code. –  Dec 04 '15 at 16:47
  • I'm also certain there's a question on here that's basically the same but I can't find it at the moment – TheLethalCoder Dec 04 '15 at 16:48
  • @TheLethalCoder Are you looking for http://stackoverflow.com/questions/21953674/in-c-families-in-a-loop-why-is-less-than-or-equal-to-more-preferred-over-just – Jarrett Robertson Dec 04 '15 at 16:49
  • @JarrettRobertson Could be... – TheLethalCoder Dec 04 '15 at 16:50
  • It depends a lot on the OS and how the OS handles the failure. In most cases it will probably just blue screen in Windows, cause a restart, and your program's execution will just halt somewhere, irrecoverably. Also you should stop thinking of code in terms of semantics but consider looking at it from a point of view of "how many clock cycles will my CPU take to execute this instruction", to which some answers may surprise you: http://stackoverflow.com/questions/12135518/is-faster-than – Alexandru Dec 04 '15 at 16:53
  • Oh, and I forgot to mention, compilers play a **HUGE** part in all of this too, depending on what optimizations they apply. You are writing C#. C# is compiled to IL using some IL compiler, IL is an intermediate language which, when run, is dynamically compiled on runtime to actual instructions using JIT, another compiler, and is then executed. – Alexandru Dec 04 '15 at 16:57

2 Answers2

2

I can sympathize with you because I felt the same way when I started programming. It's just something that you have to get used too. There's a time and place for both methods. For example, if you're using the c++ standard library, use the first method:

for (std::vector<int>::iterator it = myvector.begin() ; it != myvector.end(); ++it)

If you're just looping a fixed number of times, the convention is to use the second method:

for (unsigned int i = 0; i < N, i++)

Don't waste your time worrying about hardware problems. That's someone else's job.

Joel
  • 2,654
  • 6
  • 31
  • 46
1

I think the reason to prefer the < options (which I always use) is not to protect from hardware failures (not doable since by definition all bets are off, unless you are writing very special kernel / fw code) but to protect from logic errors (and to feel a little safer for some basic human instinct reason not for a logical reason).

The kind of error being protected against is where the loop counter is being modified inside the loop.

The counter argument is that any code that changes i to be > n is probably wrong (unless this is how somebody is forcing loop exit - a bad idea IMHO) and so you should allow the loop to run off the end of the array and fail (assuming you are on a platform that detects access of the end of an array, Java, c#,...).

pm100
  • 48,078
  • 23
  • 82
  • 145