for and while loop in c#

(update)
Actually – there is one scenario where the for construct is more efficient; looping on an array. The compiler/JIT has optimisations for this scenario as long as you use arr.Length in the condition:

for(int i = 0 ; i < arr.Length ; i++) {
    Console.WriteLine(arr[i]); // skips bounds check
}

In this very specific case, it skips the bounds checking, as it already knows that it will never be out of bounds. Interestingly, if you “hoist” arr.Length to try to optimize it manually, you prevent this from happening:

int len = arr.Length;
for(int i = 0 ; i < len ; i++) {
    Console.WriteLine(arr[i]); // performs bounds check
}

However, with other containers (List<T> etc), hoisting is fairly reasonable as a manual micro-optimisation.

(end update)


Neither; a for loop is evaluated as a while loop under the hood anyway.

For example 12.3.3.9 of ECMA 334 (definite assignment) dictates that a for loop:

for ( for-initializer ; for-condition ; for-iterator ) embedded-statement

is essentially equivalent (from a Definite assignment perspective (not quite the same as saying “the compiler must generate this IL”)) as:

{
    for-initializer ;
    while ( for-condition ) {
        embedded-statement ;
        LLoop:
        for-iterator ;
    }
}

with continue statements that target
the for statement being translated to
goto statements targeting the label
LLoop. If the for-condition is omitted
from the for statement, then
evaluation of definite assignment
proceeds as if for-condition were
replaced with true in the above
expansion.

Now, this doesn’t mean that the compiler has to do exactly the same thing, but in reality it pretty much does…

Leave a Comment