That's an example of what I meant by "cultural dialect": I learned C in the context of the Unix sources so for(;;) was the canonical way to make an infinite loop. People who came from other "cultures" (e.g. Pascal, like many Mac programmers) used loop constructs common to them.

And it's not like I don't use 'while' -- in a bash script it looks normal to me -- it's just I would never even think to use one in C or C++. And when I read it it looks weird to me.

I realized two other reasons (I can't edit my comment any more):

- 'for' is simply my only looping construct. Now that C++ supports 'for(auto x : some_container) x.blahblah();' this is especially true.

- the old 'for(init; test; increment)' syntax put all your control right up front so as you read the code you already have in mind the range of when the body will run. A 'while(not_exit) { ... }' doesn't tell you that you're, say striding over the even elements or whatnot -- it's really just the equivalent of an open loop with an 'if(...) break;' somewhere in the body. And let's not get into the botch of 'do..while'

For an infinite loop, some people prefer it because the lack of a condition means it looks simpler than while(true), and therefore signals its meaning more effectively.

I'd be very surprised if there was any difference in terms of the generated code. Personally I use while(true).

There was a very interesting little side note in John Regehr's recent CppCon talk[1] on undefined behavior: Apparently, C11 added language that forbids compilers from eliding side-effect free infinite loops if they're of the form `while (<constant expression>)` but not other loop forms. C++ has not yet adopted this language, but it might in the future.

A strange choice by the committee I'd be interested in reading more about.

[1] https://youtu.be/v1COuU2vU_w?t=2327

Not a compilers guy, so when you say "eliding loops", do you refer to optimizing out loops that the compiler assumes are side-effect free?

Coming from an embedded background, the form "while (true) { // do nothing of interest }" is seen a lot in embedded code. If your code is interrupt driven, or running certain RTOSes, you would usually see this at the end of main(), since everything happens in interrupts. You might also see this in error handlers, and "unimplemented" interrupt handlers during development, as a way to trap the program without halting / resetting the system completely. If this kind of loop was optimized out / you returned-from-main on your embedded system, interesting and unintended things may happen.

While I've never had problems with these particular loops being optimized out (that I can remember!), I do remember having to do other vary silly hacks to try and tell the compiler not to optimize things out, because something is happening in hardware that it wasn't aware of, so I wonder if this is just a practical way of making sure that this kind of code keeps working with newer compilers, even in the face of aggressive optimization.

Yes, the C and C++ standards allow compilers to eliminate loops which have no side effects (It's actually slightly more tricky than this but whatever, check the spec for the exact details). This can be tough in situations like you say, but also in other places: for example, Rust's semantics do not allow you to elide them, but because we use LLVM, we incidentally inherited this behavior: https://github.com/rust-lang/rust/issues/28728

LLVM has since added a new intrinsic: https://reviews.llvm.org/D38336

This will allow us to fix the bug.

Yes, the optimizer is allowed to completely eliminate side-effect free infinite loops.

Example: https://godbolt.org/g/md86qX

for(;;) // hmm. No condition, that's the quirky syntax for infinite loop

while(true) // infinite loop! Red flag!

repeat // I have no idea what this will do.

For(;;) allows you to put the looping variable initialization, exit condition, and increment statement in the same line, so you easily get a clear idea of those three.

I don't know why this got downvoted; true, I was referring to the infinite loop case, but this is a legit (if not C++-specific) case of a benefit of for over while.

Likewise do...while is in retrospect, a mistake, because it documents the control strategy in a bad place from a humans-understanding-code point of view.

>I don't know why this got downvoted; true, I was referring to the infinite loop case, but this is a legit (if not C++-specific) case of a benefit of for over while.

Thanks gumby.

I simply didn't catch that they were referring only to infinite loops. I though they were debating the usefulness of while versus for, in general.