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

[Andy Brummer]

:-D

Curvature of the Mind now with 3D

[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.