|
i think you just hoisted my attempt to play Hamlet on his own petard
«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'm all kinds of no fun today, sorry.
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 searches
endfor 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
|
|
|
|
|
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
|
|
|
|
|
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!)
|
|
|
|
|
I think it continues through the end of the code. I don't know that it is explicitly closed.
Frankly, I can't stand this form of pseudo code. It is like cave drawings.
Real programmers use butterflies
|
|
|
|
|
aha... and?
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Interesting that the paper you linked was headed Edgar Dijkstra when his name is Edsger.
Maybe Dutch is a bit too hard for the editors at the ACM.
|
|
|
|
|
well, my peers, and mentors, i intended this post as a tongue-in-cheek jiggery-pokery i hoped would not be taken seriously ...
back in the days some of us fossils can remember, languages, like Fortran, had simple control structures; you had to use 'goto to exit a DO loop; that, and BASIC, are the context in which Dijkstra's famous hyperbolic essay took aim [^].
in today's high-level languages, like C#, the underlying use of jumps/gotos is abstracted away for very good reasons.
if i see a while(true) in C#, i call that sloppy code that lacks documentation, and, is less maintainable, because you've got to study the interior code to figure out what, if anything, makes it stop.
and, it never returns? [^]
«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
|
|
|
|
|
Essential in embedded coding. Pretty much every non-OS based embedded app will have a while(1) or similar in the main code. Ditto for an OS, you can't schedule the scheduler (well, you *can*, but...).
|
|
|
|
|
Works better than any break point...
|
|
|
|
|
const DucksFloat = true;
:
:
while(DucksFloat) {
}
Nothing succeeds like a budgie without teeth.
|
|
|
|
|
|
The problem with any remark, comment, oneliner, if it gets overused, a number of things happen
- they get a life of their own. Everybody starts to parrot this "wisdom" because of how good it sounds
- the use of the term gets disconnected from the original meaning, because it is an easy, and thus lazy comment to make
- instead of being helpful, or any kind of contribution to the quality and ethics of software engineering, it becomes the catchphrase of choice for individuals who want their opinion to be taken for "superior" at all cost.
What everybody *should* have done instead, is work out why, or why not, they are using a particular construct, and show real professionalism that way, rather than faking it through gratuitous remarks that sit well with the boss.
|
|
|
|
|
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
|
|
|
|
|
#define ever (;;) would allow you to write
for ever {...}
|
|
|
|
|
In the development phase while(true) is fine and clear. When you are clear as to what conditions must be met to break out of the loop, we can set up a meaningful boolean eg while(NoReliablStatus) or whatever.
Replacing while(true) with while(notdone) is a waste of time.
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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!
|
|
|
|
|
while (true)
{
if (isPolitican) break;
}
|
|
|
|
|
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
|
|
|
|