for(;;) vs. while(true)

Why don't you just write a short program with a for and a while loop and debug it. DevC++ let's you see the assembly code, M$VC++ probably too.

edit:

ok, I've compiled

Code:

---

for (;;) {
  Sleep(0);
}

---

and

Code:

---

while (true) {
  Sleep(0);
}

---

and both compiled to the exact same assembly code:

Code:

---

0x4012ce <main+30>: sub  $0xc, %esp
0x4012d1 <main+33>: push $0x0
0x4012d3 <main+35>: call 0x415370 <Sleep@4>
0x4012d8 <main+40>: add  $0xc, %esp
0x4012db <main+43>: jmp  0x4012ce <main+30>

---

I just "copied" the loop because the CPU-window didn't allow copy/paste for some reason. Can anyone explain what 0x4012ce and 0x4012d8 are supposed to do ??

another edit:

If a local function is used instead, the assembler code is just a call and a jmp so I figure it was just some kind of overhead for external calls. btw, goto compiles to the same code ;)

I'm no ASM expert.. in fact the only thing I know is how to spell it..

BUT - it looks like it is moving the pointer to the stack by 12 BYTES (??), pushing the number 0 onto the stack (the argument to sleep() ). Then it calls the sleep function then restores the pointer to the stack, then returns to the begining of the loop. Not sure exactly why it subtracts 12 from the extended stack pointer though.

[edit]
ESP is the extended (32 bit) pointer to the stack, SUB is a subtraction routine where b is the source and a is the destination.
[/edit]

As for MSVC, this is what you get when you compare the two.. It looks like for (;;) uses less operations!?

Code:

---

        while (true)
00413132  xor        eax,eax
00413134  inc        eax 
00413135  test        eax,eax
00413137  je          main+36h (41314Ch)
        {
                Sleep(0);
00413139  mov        esi,esp
0041313B  push        0   
0041313D  call        dword ptr [__imp__Sleep@4 (42B20Ch)]
00413143  cmp        esi,esp
00413145  call        @ILT+1055(__RTC_CheckEsp) (411424h)
        }
0041314A  jmp        main+1Ch (413132h)

---

Code:

---

        for(;;)
        {
                Sleep(0);
00413132  mov        esi,esp
00413134  push        0   
00413136  call        dword ptr [__imp__Sleep@4 (42B20Ch)]
0041313C  cmp        esi,esp
0041313E  call        @ILT+1055(__RTC_CheckEsp) (411424h)
        }
00413143  jmp        main+1Ch (413132h)

---

Quote:

---

Originally posted by filler_bunny
is what you get when you compare the two.. It looks like for (;;) uses less operations!?

---

Finally, proof that MSVC sucks.

Hmm, interesting. One person finds that the assembly is the same and another finds that the for takes fewer operations. Well, in that case I imagine that with full optimizations they should compile to roughly the same thing, and if not, the difference should be marginal. My summary:

for(;; ) takes less time to type, and is potentially faster (very very slightly). while(true) is easier to read but is potentially slower (very very slightly).

So for the sake of code readability, I suppose I'll stick with while(1)/while(true) unless I'm really really pressed for speed :D Although somebody DID pm me about a compiler warning that for(;; ) is the "more conventional" version of an infinite loop... :rolleyes:

Quote:

---

Although somebody DID pm me about a compiler warning that for(;; ) is the "more conventional" version of an infinite loop...

---

The compiler warning for while(1)/while(true) was mentioned in the other thread. I wonder what is the warning?

>I wonder what is the warning?
warning C4127: conditional expression is constant

>warning C4127: conditional expression is constant

Hmm, interesting. I hate to go against the accepted wisdom.

I like the while(true) because it seems more intuitive. Unless you've used it before, for(;;) is cryptic. If I saw this for the first time, I would be thinking: Does this mean don't execute the for? Execute the for one time? Execute the for infinite times?

But if the conventional wisdom says use for(;;), then that is what I will use!

Its interesting looking at the difference between the two compilers asm though. It's obvious (and I just retried this with full optimization) that the MS compiler does a check for equality, checking the value of the register against itself (which presumably is where the value of true is kept for the duration of the while loop) when compiling the while loop, but it realises that no such test is required for the for loop as it is empty.

It seems like an odd design decision, not to further optimise the while loop. I guess I may have to pay more attention to my ASM output!

I always used for(;;)... but which of these would be better:

Code:

---

...
for(;;)
{
    if(variable)
          break;
    else
          continue;
}
...

---

or

Code:

---

...
while(variable)
{...}
...

---

I know all the sloppy differences I left, but that's just some stuff I wrote so you could get the basic idea of my question: is it better to break out of an infinite loop, or is it better to use the variable in a while/do-while loop?

/me groans as he sees the start of another "break is evil" flame war...

Quote:

---

It seems like an odd design decision, not to further optimise the while loop. I guess I may have to pay more attention to my ASM output!

---

I too am surprised that with optimization enabled MSVC didn't generate identical code, as DevC++ did.

As for the Major's question, I'll defer to Prelude to provide an answer.:D

Quote:

---

Originally posted by Hunter2
Hmm, interesting. One person finds that the assembly is the same and another finds that the for takes fewer operations. Well, in that case I imagine that with full optimizations they should compile to roughly the same thing, and if not, the difference should be marginal. My summary:

for(;; ) takes less time to type, and is potentially faster (very very slightly). while(true) is easier to read but is potentially slower (very very slightly).

---

No. That is not true. I am using MinGW and for (;;), while (true) and x: goto x; resolved to the exact same statements without code optimization. filler bunny's code is a MS VC++ product.

I tried to check how it looks with optimizations enabled (but what more to optimize - it's only one jmp?) but that somehow prevented gdb from finding my breakpoint, so I couldn't use the CPU window.

Anyway, that was without optimizations, so at least if you're using a decent compiler (*g*) it will be the same assembler code.

Quote:

---

No. That is not true. I am using MinGW and for (;;), while (true) and x: goto x; resolved to the exact same statements without code optimization. filler bunny's code is a MS VC++ product.

---

Yes - I suspect that MSVC is probably the only major compiler as used by visitors to this board that does things this way (for this special case).

But I have been wondering why. I suspect that the MSVC compiler is doing the "right" thing, in that the ASM produced is exactly as you would expect from the while loop (i.e. it is evaluating the statement, in this case "true" every time it enters the loop).

But it appears as though most other compilers are doing the "smart" thing in that they are making a special case for a statement that is always going to evaluate to true and resolving the "while(true)" statement to the ASM equivalent of a "for(;;)" loop.

Mm. But I'm using MSVC, so :D But are the tests for MSVC being compiled in debug mode or release mode? I thought that with release mode (i.e. full optimizations) you couldn't use breakpoints or anything :confused:

I've seen this done:

Code:

---

#define EVER ;;

for(EVER)
{
    // do stuff
}

---

I don't think that looks half bad. And that is all I have to contribute to this thread.