Is "for(;;)" faster than "while (TRUE)"? If not, why do people use it?

Question

for (;;) {
    //Something to be done repeatedly
}

I have seen this sort of thing used a lot, but I think it is rather strange... Wouldn't it be much clearer to say while (TRUE), or something along those lines?

I'm guessing that (as is the reason for many-a-programmer to resort to cryptic code) this is a tiny margin faster?

Why, and is it REALLY worth it? If so, why not just define it this way:

#DEFINE while(TRUE) for(;;)

EDIT: I'm assuming TRUE to be defined to 1 and FALSE to 0.

Thanks for your input everyone.

Answer 1

1. It's not faster.
2. If you really care, compile with assembler output for your platform and look to see.
3. It doesn't matter. This never matters. Write your infinite loops however you like.

Answer 2

It's certainly not faster in any sane compiler. They will both be compiled into unconditional jumps. The for version is easier to type (as Neil said) and will be clear if you understand for loop syntax.

If you're curious, here is what gcc 4.4.1 gives me for x86. Both use the x86 JMP instruction.

void while_infinite()
{
    while(1)
    {
    puts("while");
    }
}

void for_infinite()
{
    for(;;)
    {
    puts("for");
    }
}

compiles to (in part):

.LC0:
.string "while"
.text
.globl while_infinite
    .type   while_infinite, @function
while_infinite:
    pushl   %ebp
    movl    %esp, %ebp
    subl    $24, %esp
.L2:
    movl    $.LC0, (%esp)
    call    puts
    jmp .L2
    .size   while_infinite, .-while_infinite
    .section    .rodata
.LC1:
    .string "for"
    .text
.globl for_infinite
    .type   for_infinite, @function
for_infinite:
    pushl   %ebp
    movl    %esp, %ebp
    subl    $24, %esp
.L5:
    movl    $.LC1, (%esp)
    call    puts
    jmp .L5
    .size   for_infinite, .-for_infinite

Answer 3

Not just a well-known pattern, but a standard idiom in C (and C++)

Answer 4

Personally I use for (;;) because there aren't any numbers in it, it's just a keyword. I prefer it to while (true), while (1), while (42), while (!0) etc etc.

Answer 5

The "forever" loop is popular in embedded systems as a background loop. Some people implement it as:

for (; ;)
{
 // Stuff done in background loop
}

And sometimes it is implemented as:

while (TRUE /* or use 1 */)
{
 // Stuff done in background loop
}

And yet another implementation is:

do
{
 // Stuff done in background loop
} while (1 /* or TRUE */);

An optimizing compiler should generate the same or similar assembly code for these fragments. One important note: the execution time for the loops is not a big concern since these loops go on forever, and more time is spent in the processing section.

Answer 6

It's a matter of personal preference which way is faster. Personally, I am a touchtypist and never look at my keyboard, during programming -- I can touchtype all 104 keys on my keyboard.

I find if faster to type "while (TRUE)".

I mentally added some finger movement measurements and totalled them up. "for(;;)" has about 12 key-widths of movements back and fourth (between home keys and the keys, and between home keys and SHIFT key) "while (TRUE)" has about 14 key-widths of movements back and fourth.

However, I am vastly less error-prone when typing the latter. I mentally think in words at a time, so I find it faster to type things like "nIndex" than acronyms such as "nIdx" because I have to actually mentally spell out the lettering rather than speak it inside my mind and let my fingers auto-type the word (like riding a bicycle)

(My TypingTest.com benchmark = 136 WPM)

Answer 7

There's no difference in terms of the machine code that is generated.

However, just to buck the trend, I'd argue that the while(TRUE) form is much more readable and intuitive than for(;;), and that readability and clarity are much more important reasons for coding guidelines than any reasons I've heard for the for(;;) approach (I prefer to base my coding guidelines on solid reasoning and/or proof of effectiveness myself).

Answer 8

I've seen some people prefer it because they have a #define somewhere like this:

#define EVER ;;

Which allows them to write this:

for (EVER)
{
    /* blah */
}

Answer 9

I cannot imagine that a worthwhile compiler would generate any different code. Even if it did, there would be no way of determining without testing the particular compiler which was more efficient.

However I suggest you prefer for(;;) for the following reasons:

• a number of compilers I have used will generate a constant expression warning for while(true) with appropriate warning level settings.

• in your example the macro TRUE may not be defined as you expect

• there are many possible variants of the infinite while loop such as while(1), while(true), while(1==1) etc.; so for(;;) is likely to result in greater consistency.

Answer 10

I prefer for(;;) for two reasons.

One is that some compilers produce warnings on while(true) (something like "loop condition is constant"). Avoiding warnings is always a good thing to do.

Another is that I think for(;;) is clearer and more telling. I want an infinite loop. It literally has no condition, it depends on nothing. I just want it to continue forever, until I do something to break out of it.

Whereas with while(true), well, what's true got to do with anything? I'm not interested in looping until true becomes false, which is what this form literally says (loop while true is true). I just want to loop.

And no, there is absolutely no performance difference.

Answer 11

I personally prefer the for (;;) idiom (which will compile to the same code as while (TRUE).

Using while (TRUE) may be more readable in one sense, I've decided to use the for (;;) idiom because it stands out.

An infinite loop construct should be easily noticed or called out in code, and I personally think the for (;;) style does this a bit better than while (TRUE) or while (1).

Also, I recall that some compilers issue warnings when the controlling expression of a while loop is a constant. I don't think that happens too much, but just the potential for spurious warnings is enough for me to want to avoid it.

Answer 12

What about (if your language supports it):

start:
/* BLAH */
goto start;

Answer 13

Because of Dennis Ritchie

• I started using for (;;) because that's the way Dennis Ritchie does it in K&R, and when learning a new language I always try to imitate the smart guys.

• This is idiomatic C/C++. It's probably better in the long run to get used to it if you plan on doing much in the C/C++ space.

• Your #define won't work, since the thing being #define'd has to look like a C identifier.

• All modern compilers will generate the same code for the two constructs.

Answer 14

All good answers - behavior should be exactly the same.

HOWEVER - Just suppose it DID make a difference. Suppose one of them took 3 more instructions per iteration.

Should you care?

ONLY if what you do inside the loop is almost nothing, which is almost never the case.

My point is, there is micro-optimization and macro-optimization. Micro-optimization is like "getting a haircut to lose weight".

Answer 15

while(true)

generates a warning with Visual Studio (condition is constant). Most places I've worked compile production builds with warnings as errors. So

for(;;)

is preferred.

Answer 16

I assume while(true) is more readable than for(;;) -- its look like programmer misses something in for loop :)

and who cares which one is faster if any