Why can the condition of a for-loop be left empty? [duplicate]

Question

Possible Duplicate:
No loop condition in for and while loop

Why is the condition in a for-loop allowed to be left empty? For example

for (;;)

compiles fine. Why does this empty expression evaluate to true but the following

if () {}
while () {}

will both fail? I want to know if/why the for-loop is an exception to this case.

Answer 1

http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf

These are the iteration statements

while ( expression ) statement

do statement while ( expression ) ;

for ( expression [opt] ; expression [opt] ; expression [opt] ) statement

for ( declaration expression [opt] ; expression [opt] ) statement

The while loop was designed to evaluate the controlling expression before each execution of the loop and the do loop was designed to evaluate after each execution.

The for loop was designed as a more sophisticated iteration statement.

6.8.5.3 The for statement

The statement

for ( clause-1 ; expression-2 ; expression-3 ) statement

behaves as follows: The expression expression-2 is the controlling expression that is evaluated before each execution of the loop body. The expression expression-3 is evaluated as a void expression after each execution of the loop body. If clause-1 is a declaration, the scope of any identifiers it declares is the remainder of the declaration and the entire loop, including the other two expressions; it is reached in the order of execution before the first evaluation of the controlling expression. If clause-1 is an expression, it is evaluated as a void expression before the first evaluation of the controlling expression.

Both clause-1 and expression-3 can be omitted. An omitted expression-2 is replaced by a nonzero constant.

The specification allows expression-2, the condition of the loop, to be omitted and is replaced by a nonzero constant. This means that the for loop will continue to execute indefinitely.

This is useful for allowing a simple syntax for iterating with no end.

for(int i = 0;;i++) { //do stuff with i }

That's much simpler to write and understand than writing a while(1) loop with a variable declared outside the loop and then incremented inside the loop.

The for loop specification then goes on to allow you to omit clause-1 so that you can declare or initialize variables elsewhere, and you can omit expression-3 so that you are not required to evaluate any expression upon completion of each loop.

The for loop is a special case. The while loop and the do loop are strict and require an expression, but the for loop is a flexible iteration statement.

Answer 2

I can't give a definitive answer, but my guess would be that it's because in the for loop case, there are three different expressions, each of which you may or may not need to use depending on the loop.

In the if case, it would make no sense if there were no expression; it would need to always act as if the expression were true or false, and thus be equivalent to just one of the clauses alone. In the while case, there would be a meaningful interpretation of while () { }, which would be to evaluate to while (1) { } (giving you a loop that you can break out of with break), but I guess that the benefits of leaving out that single character are not worth the trouble.

However, in the for loop case, there are three different expressions, each of which may or may not be needed. For instance, if you want to initialize and increment something on every loop, but will use break to break out of the loop, you can write for (i = 0; ; ++i), or if you just want the test and increment, because your variable is already initialized, you could write for (; i > 0; --i). Given that each of these expressions may not be necessary depending on your loop, making you fill in a placeholder for all that you do not use seems a bit cumbersome; and for consistency, rather than requiring a placeholder in one of them, all of them are optional, and the condition is considered to be a constant non-zero value if omitted.

Of course, it is sometimes easy to read too much intent into a design decision. Sometimes, the reason for a given standard is simply that that's how it was implemented in the first implementation, and everyone else just copied that. For an example, see Rob Pike's explanation of why files starting with . are hidden in Unix; it wasn't due to a deliberate design decision, but simply because someone took a shortcut when writing ls and didn't want to display the . and .. directory entries every time.