while (true) and for (; ; ) [modified]

[Steve Mayfield]

Those constructs are usually seen in non-ineractive microprocessor embedded systems - I use them all of the time for the main "idle loop". I rely on a watchdog timer to restart the application if something hangs.

Steve _________________ I C(++) therefore I am

[Dan Neely]

Unfubarring the mess and then fixing it typically takes me less time than trying to patch the fubar.

3x12=36 2x12=24 1x12=12 0x12=18

[Lost User]

The only place I can remember using endless loops is in thread procedures. There often is no break, but of course I catch the ThreadAbortException to exit the loop. For example, a 3D rendering thread would be started at the beginning of the application and render as many frames as fast as it can until the thread is ended. Ending threads with an exception always appeared a little strange to me, because this definitely is changing the program flow with exceptions, but at least it has worked as expected up to now.

"I just exchanged opinions with my boss. I went in with mine and came out with his." - me, 2011

[Lost User]

I wrote it below: A thread procedure without a clear number of iterations. Threads are terminated with an exception, but I also think that's not clean. But Bill wants it that way.

"I just exchanged opinions with my boss. I went in with mine and came out with his." - me, 2011

[RugbyLeague]

I implement it - it just doesn't do anything. I like how a "using" easily and obviously defines a scope for a class. using(var foo = new foo()) { foo.DoStuff(); } feels better than: var foo = new foo(); foo.DoStuff(); because in the latter foo is still in scope after use - the former more explicitly defines the useful lifetime of foo - I know there are other probably more correct ways of doing this. I just like the "using" notation. I don't always use it of course.

[hairy_hats]

bob16972 wrote:

I personally prefer while(TRUE) so as not confuse any VB programmer that comes across my code.

:confused: Isn't that a reason to use for(;;) ?

[alanevans]

I'd prefer someone do this:

while(true)
{
if(matched condition A)
{
do something A
break;
}

if(matched condition B)
{
do something B
break;
}

}

to this:

bool exit = false;
while(!exit)
{
if(matched condition A)
{
do something A
exit = true;
continue;
}

if(matched condition B)
{
do something B
exit = true;
continue;
}
}

It's messy, longer and more prone to bugs when being supported/extended, and all just to avoid the "infinite loop", even though really it's just as "infinite".

[Stefan_Lang]

I never do that. Every loop has legitimate conditions that should cause it to stop, be it timeout, an external command to stop (assuming the loop handles such commands), reaching the end of data, reaching the max number the loop counter type can hold (if you are using a counter, don't risk overflow!), whatever. Such cases are not exceptions! So they need to be treated and inquired appropriately. A good way to deal with hard to define termination conditions is to introduce and maintain a state variable. It can be a bool, an enum type, or even a struct that can hold additional information, such as the reason(s) for the most recent state change(s). You can even make it a class that treats it's own reporting, special logging and debug behaviour. Even for debugging an testing I define at the very least a maximum count.

[M Towler]

I use these when the structure of the code dictates it would be helpful to have the loop termination condition in the *middle* of the loop. Something like the following for(;;) { // do some stuff if( stuff is now done ) break; // more stuff } Otherwise the alternative is to replicate the "// do some stuff" code before the first loop iteration, which is avoidable duplication. The other way to achieve this is to put "// do some stuff" into a function, then use the comma operator in the loop condition to execute some code first. I tend to regard the comma operator as a very last resort though, most programmers don't even realise it exists let alone how to use it.

[alanevans]

I sometimes do this in C:

void method(void)
{
//initialization, e.g. mallocs
do //think try
{
//some stuff

if(early exit condition)
{
break; //continue is also fine
}
//other stuff (but skipped in event of early exit condition)

} while(false); //think finally
//finalization, e.g. frees
}

This effectivly gives me a try...finally in C. Which helps reduce ifs nesting.

[Jun Du]

While(!done) won't prevent you from exiting in the middle of the loop. You can break anywhere you like. The point is that I prefer to use a loop in a controlled manner.

Best, Jun

[Alan Balkany]

It depends on what the application calls for. There are numerous situations where while(true) is appropriate. Three years ago I did an application where the spec explicitly said to not handle shutting down the application. It was a long-running application, and my guess was they would simply shut down the computer when done. What about a heart pacemaker? If it exited the loop, someone might die.

[CPallini]

Jun Du wrote:

While(!done) won't prevent you from exiting in the middle of the loop. You can break anywhere you like.

Well that would look (to me) redundant. It's just matter of personal taste, but I think if .. break in the middle of the loop is a 'controlled manner' too. :)

If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles]

[Andrew Glowacki]

while(true) { lock(syncObject) { if (checkSomeCriticalCondition()) break; } doSomeOtherStuff(); }

[Nish Nishant]

Uhm, what's your point? :-) You do have a break there (which is an exit point)! So yours is not an exit-less infinite loop!

Regards, Nish

---

New article available: Resetting a View Model in WPF MVVM applications without code-behind in the view My technology blog: voidnish.wordpress.com

[Andrew Glowacki]

I know, just giving a solid example so there's no doubt. ;P

[Nish Nishant]

Andrew Glow wrote:

I know, just giving a solid example so there's no doubt.

Thanks for the 1 vote.

Regards, Nish

---

New article available: Resetting a View Model in WPF MVVM applications without code-behind in the view My technology blog: voidnish.wordpress.com

[Jun Du]

Yes, they are both "controlled". There is a slight difference. "if...break" can exit anywhere within the loop, whereas while(!done) exits at the end of a loop.

Best, Jun

[Fabio Franco]

I have used this only once in production. It's a windows service application that listen to connection requests on a background thread. Something like this:

while(true)
{
m_Socket = m_Listener.AcceptSocket(); // This is a blocking line which waits until a connection request arrives from the clinet.

//Do stuff from the connection request, then start over to keep listening for new requests

}

Of course this code is part of a method that is enclosed on a try catch block that expects a ThreadAbortedException. Which is the way out of the loop. And that only happens when the user explicitly asks to do so or the service is stopped. I think the while(true) can be used, but with lot of care. And I think that there are very few scenarios where the danger of it's use is smaller than the need. So, if you can avoid it, avoid it. If not, make sure you know what you're doing and try to cover as many possibilities of things going wrong as possible.

[jsc42]

CPallini wrote:

you may know in the middle of the loop that you've to exit and while you may skip the following statements with an if and then use the condition, I prefer an immediate break.

What you have described is known as an n-and-a-half times loop. The Pascal P-Code compiler uses the following ungainly way of doing it (excuse the non-PASCAL syntax ... my Pascal is extremely rusty, but the principle is clear)

DO
(* bits before the test *)
test = exit condition;
IF (NOT test)
(* bits after the test condition *)
UNTIL (test)

It always struck me as bad - the compiler writers having to use an idiom to do something that their language did not support cleanly - surely, they should be able to adjust the language when they saw its inherent deficiencies. Languages that I was involved with in the late 1970s always 'magically' got extensions that supported n-and-a-half times loops. For example, my Rationalised FORTRAN (which included block structured constructs long before FORTRAN 77 became available) had:

LOOP
bits before the test
EXITIF condition // You could have multiple EXITIF sections
bits after the test
ENDLOOP

(minor later variant was an EXITIFNOT statement as an alternative to EXITIF) A WHILE loop then simply becomes

LOOP
EXITIFNOT condition
body of the loop
ENDLOOP

An UNTIL loop then simply becomes

LOOP
body of the loop
EXITIF condition
ENDLOOP

A normal FOR/NEXT or DO/CONTINUE loop becomes

controlvar = startvalue
LOOP
EXITIF controlvar > endvalue
body of the loop
controlvar = controlvar + step
ENDLOOP

A 'must do at least once' FOR/NEXT or DO/CONTINUE loop becomes

controlvar = startvalue
LOOP
body of the loop
controlvar = controlvar + step
EXITIF controlvar > endvalue
ENDLOOP

Example: To see if an item is in an array

i = 1 // Lower bound of subscript
LOOP
EXITIF i > noofelementsinthearray
EXITIF array(i) = valuetofind // Previous EXITIF ensure that array subscript overflow will not occur
i = i + 1
ENDLOOP

or

i = 1 // Lower bound of subscript
LOOP
EXITIF i > noofelementsinthearray
IF (array(i) = valuetofind)
do whatever you want with the found value
EXITIF true // I never got around to creating a simple unconditional EXIT statement!
END IF
i = i + 1
ENDLOOP