for(;;) is faster than while(1) because it doesn't have to check a condition on every pass. Other than that, they're basically equivalent.
Name:
Anonymous2010-07-02 13:52
You can write small loops inside the for(;;), and they generally work faster. while/break is better for abstracting state.
for(;;) does not check for condition while(?) needs a condition to work.
>>2,3
>for(;;) is faster than while(1) because it doesn't have to check a condition on every pass
while(1) also does not have to check the condition, since it's constant. Read your SICP and Dragon book.
Name:
Anonymous2010-07-02 14:30
For is more flexible, but less readable.
Name:
Anonymous2010-07-02 14:35
They're both awful constructs that the imperative devil created to keep you stupid.
>>10
It's not second-guessing, it's called optimization. If you don't want your compiler to ``second-guess'' you, you should use assembly. Yes, I know that it's not called a ``compiler''.
>>15
Of course it's second-guessing. It's perfectly fine if it does it in -O1 or higher, but regular compilation should not fuck with your algorithm like that.
>>16
The difference between for (;;) and while (1) is not ``fucking with your algorithm''. They both do the exact same thing, and should compile to the same assembly.
>>17
They don't do the same thing, and you're a moron for thinking they do. A proper compilation of while (1) will be slightly slower than a proper compilation of for (;;). If I want to write for (;;) I will, and the compiler should not get in my way if I write while (1) instead.
>>23
The standard does guarantee that the condition for a while loop is checked on every pass, however. If your compiler produces the same assembly for while (1) and for(;;), it is broken.
Name:
FrozenVoid2010-07-03 1:22
If i need a real fast Infinite loop i use
label1:
loop();if(done){goto label2;}
goto label1;
label2://beats all those for/while loops and has zero overhead.
>>24
if the compiler can determine that checking the condition has no side effects and the condition cannot possibly change, it doesn't have to check it on every pass. if the condition is a compile-time constant, it doesn't have to check it at all. the standard only guarantees that it will be checked on every pass if checking the condition has side effects or the condition can change.
Name:
Anonymous2010-07-03 1:40
>>24
C99 5.1.2.3p3: In the abstract machine, all expressions are evaluated as specified by the semantics. An actual implementation need not evaluate part of an expression if it can deduce that its value is not used and that no needed side effects are produced (including any caused by calling a function or accessing a volatile object).
>>27-28
The important part here is if the condition has no needed side effects, which it clearly does, or the programmer would have used the more sensible for(;;) construct.