'Infinite loops - top or bottom? [closed]
In the spirit of questions like Do your loops test at the top or bottom?:
Which style do you use for an infinite loop, and why?
- while (true) { }
- do { } while (true);
- for (;;) { }
- label: ... goto label;
Solution 1:[1]
while(true) {}
It seems to convey the meaning of the loop most effectively.
Solution 2:[2]
for (;;)
{
/* No warnings are generated about constant value in the loop conditional
plus it is easy to change when you realize you do need limits */
}
Solution 3:[3]
#define forever for(;;)
forever {
/*stuff*/
}
Solution 4:[4]
while(1)
{
//do it
}
That's how I roll.
Solution 5:[5]
I like to use the for(;;) approach because the MSVC++ compiler complains about while loop approach:
void main()
{
while(1) // test.cpp(5) : warning C4127: conditional expression is constant
{
}
for(;;)
{
}
}
Solution 6:[6]
I prefer while(1) or while(true) -- it's the clearest. do { } while(true) seems like needless obfuscation. Likewise, for(;;) can be confusing to people that have never seen it before, whereas while(true) is very intuitive. And there's absolutely no reason to do label: ... goto label;, it's just more confusing.
Solution 7:[7]
10 some l33t code
20 goto 10
Solution 8:[8]
I usually use for(;;) { } which I always think of as "for-ever".
Some languages offer a repeat { } construct which will natively loop forever. I find the for(;;) { } construct visually the most similar to this because it is so different from the normal for() construct. This is an important attribute for an infinite loop that while(1) { } doesn't really have.
Solution 9:[9]
Infinite tail-recursion ;)
It's somewhat compiler-dependant...
Solution 10:[10]
I use for (;;) in C-style languages and while true in languages that don't support that construct.
I learned the for (;;) method in K&R and it has always felt like idiomatic C to me.
Solution 11:[11]
Let the flaming begin...
If the loop is a true infinite loop (i.e. there is no break condition -- only an external event can terminate the thread's/process' execution), then I actually prefer the label and goto. Here's why:
First, the use of while, for, and do ... while, all imply that the loop might terminate. Even if the terminating condition is never achievable, the syntactical meaning of these constructs is that there is some termination condition.
Second, using a loop construct introduces an extra level of indentation. I hate indentation that's not necessary. It wastes valuable columnar real-estate.
Third, the only true infinite loop is the one that unconditionally jumps back to the beginning of the loop. Only goto fits that purpose exactly.
The truth is I don't really care that much about it. They all get the job done and most will result in the exact same assembly instructions anyway. However, the assembly that's generated will in all probability be an unconditional jump (if you're optimizer is worth a damn), which maps directly to which C construct, kids? That's right... your old friend goto.
Solution 12:[12]
When writing code for myself I use for(;;). Other people tend to be confused by its syntax and so for code that other people must see/use, I use while(true).
Solution 13:[13]
offtopic: if you think about what you are trying to express, you usually won't need an infinite loop.
Solution 14:[14]
for(;;);
Filler text.
Solution 15:[15]
for (;;) is what I usually see.
Solution 16:[16]
Infinite loops are a bad idea, but in practice that doesn't always hold up.
I prefer while(1) { } but make sure something within the loop can cause it to break out.
Solution 17:[17]
I usually use while() {}, but after learning that for(;;) {} isn't some sort of crazy invalid syntax, I'll be sure to use the more unique option.
Differentiates infinite loops from actual conditionals, you see.
Solution 18:[18]
I now prefer the "for (;;)" idiom because it seems to 'stick out' more. I used to use the "while (true)" idiom because I thought it expressed intent better, but I've switched over because I think the "for (;;)" idiom is well known enough to adequately express intent as well as I believe it's better by being more visible.
Kind of like how Stroustrup made the new casts in C++ purposefully ugly - so they stick out.
Sources
This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.
Source: Stack Overflow