Is for(;;) bad?

[Stupebrett]

Is using for(;;) { //code } considered bad programming practice, even if it is possible (in the code) to break out from the loop inside the loop?

[Moschops]

I tend to use while(1) to create a forever loop, but for(;;) is well enough known that it's recognised as a forever loop, and most compilers these days should recognise it as such and optimise to a single JMP instruction.

[ModShop]

It really just depends on what your using it for. It is possible, using break or goto, to exit an infinite loop.

[andywestken]

While I never use it by preference, there are cases where it is easier to code something understandable using for( ; ; ) / while(1) plus a bail out than using a normal loop condition.

I now favor for( ; ; ) because I build at W4 (with Visual C++) and while(1) results in complaints from the compiler that the "conditional expression is constant".

while(1), or even better while(true), does read better, though.

[shacktar]

@andywestken, I guess this reduces the readability somewhat:

#pragma warning(disable: 4127)
while(true)
#pragma warning(default: 4127)
{
    ...
}

[andywestken]

To me it's less readable than for( ; ; )

[Stupebrett]

I made this topic since I think I somewhere read that infinite loops are bad, even if you can break out of them. This seems not to be the case now after getting some of your opinions. Thanks!

[beginning]

all of your opinions is benefical to me, i also learning ,,,

[bluecoder]

the right way to do it is

while( 1) 
{
      if( condition == satisfied) 
         break; 
}

[shacktar]

@andywestken, that was mostly a joke. Putting pragmas around every while(true) would be pretty cumbersome.

This would make the warning go away as well:

while(bool infiniteLoop = true)

[1yR4jE8b]

I never understood why people sometimes prefer this:

while( 1) 
{
      if( condition == satisfied) 
         break; 
}

over

while(condition == satisfied)
{
}

do
{
}while(condition == satisfied);

[Stupebrett]

The first one may be preferable if the while loop is (very) large, and there's several conditions that can break out from the loop. Then it's easier to do the check right after something that may cause the loop to break was done, instead of checking everything at the start or the end of the loop.

[Gaminic]

The advantage (as Stupebrett hinted) is that by using in-loop breaks to stop the flow, you can skip the rest of the in-loop code.

Yes, you can rework your code so that you can check it in the loop condition, but often you'll want to group your code to where it makes sense. Imagine an algorithm that skips to a next decision moment: you'll want every iteration of the loop to work on a single decision moment value, but it might be possible to discover very early in a decision moment that it's useless. Rather than forcing some next-deicision-moment calculations at the end of the loop, or in the condition, you can use break statements early on.