while(true) is not fun
-
for (;;)
{
Console.WriteLine("this, and while(true) loops, are an abomination ... as evil as using goto");// break; // oh, go on forever}
but, writing this was fun :wtf: suggested reading: [^]
«One day it will have to be officially admitted that what we have christened reality is an even greater illusion than the world of dreams.» Salvador Dali
What about embedded systems? A lot of embedded systems have initialisation code and then the remainder of the system is handled in a single while loop, that's more or less standard practise
-
for (;;)
{
Console.WriteLine("this, and while(true) loops, are an abomination ... as evil as using goto");// break; // oh, go on forever}
but, writing this was fun :wtf: suggested reading: [^]
«One day it will have to be officially admitted that what we have christened reality is an even greater illusion than the world of dreams.» Salvador Dali
When I need an infinite loop, I do it accidentally.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013 -
for (;;)
{
Console.WriteLine("this, and while(true) loops, are an abomination ... as evil as using goto");// break; // oh, go on forever}
but, writing this was fun :wtf: suggested reading: [^]
«One day it will have to be officially admitted that what we have christened reality is an even greater illusion than the world of dreams.» Salvador Dali
It's probably been said, but try to do embedded software with out infinite loops. The only time I have seen goto used in the wild was in a avionics control software!
-
state machines are a good argument for gotos. It is impossible as far as I know, to implement every scenario possible for a deterministic finite automata based state machine without using either array based tables, or goto statements. while/for/etc don't cut it because the flow can become too complicated for those constructs. There was a Knuth paper you linked to earlier** that presented a defense of goto that is similar to my defense of it just above. ** here's the code from that paper (Example 1):
for i := 1 step 1 until m do.
if A[i] = x then go to found fi;
not found: i := re+l; m := i;
A[i] := x; B[i] := 0;
found: B[i] := B[i]+I;rewritten without goto it's even worse (Example 1a):
i:=1;
while i < m and A[i] # x do i :-- i+1;
if i > m then ra := i; A[i] := x; B[i] ::= 0 fi;
B[i] := B[i]+I;Real programmers use butterflies
Knuth's "Example 1" problem using structured statements for alternate loop exits:
for i in 1:m do
// main loop body; may contain any number of statements:
while A[i] != x; // premature loop termination if x is found
exitwhile // do this on premature loop termination, i.e. "found"
B[i]++;exitfor // do this if loop reaches end of (valid) A[], i.e. "not found"
A[i] := x;
B[i] := 1;
m = i; // new search limit for subsequent x searchesendfor
I really miss this construct; I found it truly useful, but have seen it in a single language only, 30+ years ago. Note that both the exitwhile and exitfor clauses are within the scope of the loop statement, with access to the loop control variable and any other variable declared within the loop. (This is essential to the usability of the construct.)
-
Microsoft's CodeDOM renderer for C# spits out loops like that. I've also seen Microsoft code that does it this way in the reference source for the .NET BCL. As far as the while, I prefer:
var done = false;
while(!done) {
// do work
}But every C# dev should know how to write
while(true) { }Real programmers use butterflies
honey the codewitch wrote:
But every C# dev should know how to write
while(true) { }while (true)
{
Console.WriteLine("C# is better than Javascript!");
}Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies. -- Sarah Hoyt
-
for (;;)
{
Console.WriteLine("this, and while(true) loops, are an abomination ... as evil as using goto");goto get\_me\_out\_of\_here;}
get_me_out_of_here:
Now you have it all :laugh:
-
I once had a code-reviewer change my code because I used a
while(true). This was done on the principle that one should never use awhile(true). The problem is, anyone looking at the code in future may see the condition he used and wonder why, as the condition can never be met. At least my original code is in the version history.“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
-
for (;;)
{
Console.WriteLine("this, and while(true) loops, are an abomination ... as evil as using goto");// break; // oh, go on forever}
but, writing this was fun :wtf: suggested reading: [^]
«One day it will have to be officially admitted that what we have christened reality is an even greater illusion than the world of dreams.» Salvador Dali
while (true)
{
if (isPolitican) break;
}Latest Articles:
Thread Safe Quantized Temporal Frame Ring Buffer -
Knuth's "Example 1" problem using structured statements for alternate loop exits:
for i in 1:m do
// main loop body; may contain any number of statements:
while A[i] != x; // premature loop termination if x is found
exitwhile // do this on premature loop termination, i.e. "found"
B[i]++;exitfor // do this if loop reaches end of (valid) A[], i.e. "not found"
A[i] := x;
B[i] := 1;
m = i; // new search limit for subsequent x searchesendfor
I really miss this construct; I found it truly useful, but have seen it in a single language only, 30+ years ago. Note that both the exitwhile and exitfor clauses are within the scope of the loop statement, with access to the loop control variable and any other variable declared within the loop. (This is essential to the usability of the construct.)
Yeah - i posted an alternate he provided in that same comment.
Real programmers use butterflies
-
Microsoft's CodeDOM renderer for C# spits out loops like that. I've also seen Microsoft code that does it this way in the reference source for the .NET BCL. As far as the while, I prefer:
var done = false;
while(!done) {
// do work
}But every C# dev should know how to write
while(true) { }Real programmers use butterflies
At least GOTO got a name of a style - spaghetti code!
-
Yeah - i posted an alternate he provided in that same comment.
Real programmers use butterflies
-
for (;;)
{
Console.WriteLine("this, and while(true) loops, are an abomination ... as evil as using goto");// break; // oh, go on forever}
but, writing this was fun :wtf: suggested reading: [^]
«One day it will have to be officially admitted that what we have christened reality is an even greater illusion than the world of dreams.» Salvador Dali
Once I found in the company's common "utility" .H file, this line: #define ever (;;) so you could write: for ever { ....} But, all of this ignores one basic truth of code: ALL LOOPS END! -- one way or another. Somewhere buried in your code is something along the lines of: if (realExitCondition) break; so you might as well put it into the `while()`.
Truth, James
-
I didn't find the alternative nearly as explicit and comprehensible as the exitfor/exitwhile mechanism.
True, it's not. I was simply pointing out that he *did* produce an alternative. As for me I'd prefer a state machine example. Compiled state machines requires gotos (i'm excluding array driven ones here). It's true that some state machines can be implemented without them, but not all of them can. The reason is you need to goto into and out of loops all of the time, just because of how they work. Furthermore state machines more clearly translate to drawn graphs which then directly map to the code, making the code easy to follow if it uses gotos, but not if it uses the array driven style. In this article[^] there's some coverage of what that looks like.
Real programmers use butterflies
-
for (;;)
{
Console.WriteLine("this, and while(true) loops, are an abomination ... as evil as using goto");// break; // oh, go on forever}
but, writing this was fun :wtf: suggested reading: [^]
«One day it will have to be officially admitted that what we have christened reality is an even greater illusion than the world of dreams.» Salvador Dali
I once wrote the following code: var HellFreezesOver = false do until(HellFreezesOver) // code loop The language I was working in didn't have the concept of an infinite loop and I needed one for this application. Of course, the application terminated when the Red Sox won the World Series in 2004.
-
Once I found in the company's common "utility" .H file, this line: #define ever (;;) so you could write: for ever { ....} But, all of this ignores one basic truth of code: ALL LOOPS END! -- one way or another. Somewhere buried in your code is something along the lines of: if (realExitCondition) break; so you might as well put it into the `while()`.
Truth, James
James Curran wrote:
But, all of this ignores one basic truth of code: ALL LOOPS END!
Because no device with embedded code will last forever. So you could include some sort of "while (this device is not being decomposed into its constituents for recycling purposes) {...}". The question is how the device can perform this test, and take the proper actions to terminate the loop. Lots of embedded infinite loops won't even survive a change of battery. Yet the problem is the same: A test like "while (battery power is available) {...}" has a fairly low probablity of being able to perform a loop exit. Larger systems, e.g. running databases, may have UPS systems that allow them to do a controlled shutdown, such as to write in-memory logs to stable storage. Lots of servers, both web servers and other kinds of servers, are stateless and have no data to save between requests. They sit waiting for a request, process it, and sit down waiting for the next request. There is nothing to do if the machine is turned off, the process is forcefully terminated, or a power outage occurs. So why should they have a loop exit handling? It has no meaning. Their purpose is to run indefinitely. If it stops, it stops within its loop.
-
I once wrote the following code: var HellFreezesOver = false do until(HellFreezesOver) // code loop The language I was working in didn't have the concept of an infinite loop and I needed one for this application. Of course, the application terminated when the Red Sox won the World Series in 2004.
-
James Curran wrote:
But, all of this ignores one basic truth of code: ALL LOOPS END!
Because no device with embedded code will last forever. So you could include some sort of "while (this device is not being decomposed into its constituents for recycling purposes) {...}". The question is how the device can perform this test, and take the proper actions to terminate the loop. Lots of embedded infinite loops won't even survive a change of battery. Yet the problem is the same: A test like "while (battery power is available) {...}" has a fairly low probablity of being able to perform a loop exit. Larger systems, e.g. running databases, may have UPS systems that allow them to do a controlled shutdown, such as to write in-memory logs to stable storage. Lots of servers, both web servers and other kinds of servers, are stateless and have no data to save between requests. They sit waiting for a request, process it, and sit down waiting for the next request. There is nothing to do if the machine is turned off, the process is forcefully terminated, or a power outage occurs. So why should they have a loop exit handling? It has no meaning. Their purpose is to run indefinitely. If it stops, it stops within its loop.
Quote:
Because no device with embedded code will last forever. So you could include some sort of "while (this device is not being decomposed into its constituents for recycling purposes) {...}". The question is how the device can perform this test, and take the proper actions to terminate the loop.
Even the most standard loop (`for(int i=0; i < str.Length; ++i)`) will not survive a power cut, so that's not the case we are interested in. Most embedded systems still have a "power" switch, which is not hard-wired to the power, but instead, starts the "power-down" procedure. Hence: while (!shutting_down()) {}
Truth, James
-
state machines are a good argument for gotos. It is impossible as far as I know, to implement every scenario possible for a deterministic finite automata based state machine without using either array based tables, or goto statements. while/for/etc don't cut it because the flow can become too complicated for those constructs. There was a Knuth paper you linked to earlier** that presented a defense of goto that is similar to my defense of it just above. ** here's the code from that paper (Example 1):
for i := 1 step 1 until m do.
if A[i] = x then go to found fi;
not found: i := re+l; m := i;
A[i] := x; B[i] := 0;
found: B[i] := B[i]+I;rewritten without goto it's even worse (Example 1a):
i:=1;
while i < m and A[i] # x do i :-- i+1;
if i > m then ra := i; A[i] := x; B[i] ::= 0 fi;
B[i] := B[i]+I;Real programmers use butterflies
Where does the block of the for statement end, please? I looked at the original article, page 266 for those interested, but I'm still not clear on it.
honey the codewitch wrote:
for i := 1 step 1 until m do. if A[i] = x then go to found fi; not found: i := re+l; m := i; A[i] := x; B[i] := 0; found: B[i] := B[i]+I;
-
Where does the block of the for statement end, please? I looked at the original article, page 266 for those interested, but I'm still not clear on it.
honey the codewitch wrote:
for i := 1 step 1 until m do. if A[i] = x then go to found fi; not found: i := re+l; m := i; A[i] := x; B[i] := 0; found: B[i] := B[i]+I;
Looks as if someone has done a rather unsuccessful OCR of the Knuth paper :-) Preserving the indents and correcting the OCR errors (I should be 1, re should be m) make it look like
for i := 1 step 1 until m do.
if A[i] = x then go to found fi;
not found: i := m+1; m := i;
A[i] := x; B[i] := 0;
found: B[i] := B[i]+1;So, the for loop body is no more than the 'if .. goto' statement. (Yet, even if this was in 1974, I am surprised that Knuth made that messy layout - especially the four statements after the 'not found' label. Structured statements came in Algol in 1960; Pascal arrived in 1970, so ideas of proper identetation and formatting shouldn't be new to him!)
-
Quote:
Because no device with embedded code will last forever. So you could include some sort of "while (this device is not being decomposed into its constituents for recycling purposes) {...}". The question is how the device can perform this test, and take the proper actions to terminate the loop.
Even the most standard loop (`for(int i=0; i < str.Length; ++i)`) will not survive a power cut, so that's not the case we are interested in. Most embedded systems still have a "power" switch, which is not hard-wired to the power, but instead, starts the "power-down" procedure. Hence: while (!shutting_down()) {}
Truth, James
James Curran wrote:
Most embedded systems still have a "power" switch, which is not hard-wired to the power, but instead, starts the "power-down" procedure
What do you plan to to in this omnipresent "power-down" procedure when there is nothing to save or cleanup? If your code runs multiple threads, each executiong an infinite loop (which is quite common in embedded code), will you broadcast a 'power-down' message to each of these loops and let them all take various terminating actions? Conceptually, almost all interrupt handlers are infinite loops, making another iteration when an interrupt is received. Will you signal the 'power-down' to each handler as well, for them to do their termination handling? If there are cleanup actions to be done for one, or possibly a couple, of the threads, you should of course send these theads a termination request for orderly shutdown. But lots of embedded threads, or even complete embedded systems, have no cleanup requirements. They have no need for any 'shutting down' signal, but can be cut off without formalities, just like when power disappears. The CHILL language was specifically designed for embedded systems (specifically: phone switches), and it provided an explicit loop mechanism: 'for ever do ...'. Phone switches are also illustrating that the system as a whole is designed for never terminating. If a phone switch stops running, it is due to an error or other exceptional condition; the code design assumes perpetual running.
