GOTO is alive and well. Dijkstra, eat my pants

As if BIOS tests give accurate results anyway. I've seen memory that always test OK by the BIOS even when doing the slow test, but fails when HIMEM.SYS /TESTMEM:ON is used. Not to mention the memory that passes the HIMEM test and fails on MEMTEST86 or Linux kernel compiles.

At any rate you're still incorrect because some PC BIOS's will say XXXXX skipped or some other variation.

What has Dijkstra to do with this?

Pieter

So what makes you think they've used a GOTO? Have you disassembled the BIOS?

Steve

The 'goto' instruction is actually alive and well in a lot of compiled code. I've disassembled a lot of FOR loops that start with a 'goto' (or branch or jmp) over the internals of the loop and to the terminating condition test at the end of the code. I suppose the same sequence is used in 'while(!KeyPressed() ){....}.

Mark Borgerson

Maybe you all have missed professor Dijkstra's point: The main idea in his paper was that the code *must* be constructed from simple blocks with one entry and one exit only. The components of a block can then be similar blocks. The common high-level language constructs belong to this class: if-then, if-then-else, do-while, while, switch and procedure call.v

The prohibited use of jumps (branches, goto's) is to enter the insides of another block from the side (not ia the only allowed main entry), as this usage leads to tangled spaghetti code soon resembling the Gordion's knot.

Tauno Voipio tauno voipio @ iki fi

He hasn't, that's the point. His 1975 "How to we tell truths that might hurt?" (re: "IBMerese" and later on "IBM equipment") coupled with his warnings on the use of GOTO are cheerfully alive and well in the above example.

Cheers Robin

In assembler, one implements closed constructs with jumps. That's all you've got ;).

Exactly so.

Steve

Yes, but look at the second reference in Djikstra's letter: Bohm and Jacopini.

John

That doesn't mean that Dijkstra _didn't_ make the statement that "goto's" were a bad thing and should be avoided. It appears that Böhm et al showed that gotos weren't required for Turing completeness outside of the the rules given [I haven't read their paper].

Dijkstra's point is that that not only can they be avoided, they _should_ be avoided because they result in unreadable and unmaintainable code. Dijkstra doesn't claim to have invented that opinion (he explicitly states others have made that point before). Dijkstra was, however, the one who summed it up and made it famous.

So the answer to the question about whether the poster was confusing Dijkstra with Böhm et al, is "no". The editorial cited was written by Dijkstra and is that which was being aluded to. I simply can't believe that Dijkstra's name doesn't pop into the head of anybody with a CS background when the topic of avoiding goto's is raised.

Dijkstra et al probably didn't write much code in the real world, where a major part of the work is error handling - an absolute nightmare to do in any sort of 'structured' way. On Error Goto is efficient and clear.

They should display "2^X Probably okay."

Now go back and look at the references in the footnote, reference [2] in particular. Dijkstra had more to say than what is claimed above to be the "main idea." It was based on that, but he properly attributed it.

Nor did anyone claim so.

I have. If you're interested in such things, I think Ed Yourdon's "Classics in Software Engineering" is once more in print.

Exactly. But this is not what Tauno Voipio claimed to be his "main point." That's what I was pointing out.

I disagree. The point that the poster cited was actually the point that Bohm et al made. Djikstra's point was as you describe above.

Nit: the article was actually published as a letter to the editor, iirc because the editor thought it important enough to bypass the usual preliminaries to publishing an article. I have a copy of that issue of Communications in a box somewhere. In the same box with the last issue of Micro Cornucopia :-)

part of the work is

On Error Goto is

Of course they are efficient. But the implications of such a go-to are far from clear. Sometimes error handling requires de-allocating resources to make a decent recovery from the error. If you react to an error with a go-to, then you have to manually check each and every place where such a go-to is used to see if it is in such a context that it requires some clean-up. Later on, if you add something to the code that allocates a resource, you might miss that go-to in checking where clean-up is required. Although it seems messy (not a "nightmare") A structured recovery does provide a lot of automatic clean-up, resulting is less buggy code.

-Robert Scott Ypsilanti, Michigan (Reply through this forum, not by direct e-mail to me, as automatic reply address is fake.)

major part of the work is

way. On Error Goto is

I hear this argument a lot, and it's bollocks, to be blunt. I do do a lot of real-world programming. I'm very hot on error handling (someone once said that the quality of a piece of code could be inferred by its error handling, and I'd buy that). I haven't used a goto (in C etc) since the late 70s when I learned how to avoid them. Nasty, nasty things ;).

As another poster has said, there are better ways which don't break structure. State machines spring to mind.

BTW, Dijkstra was no simple theorist. He virtually wrote the book on real-world programming.

Steve

"Steve at fivetrees" schreef in bericht news: snipped-for-privacy@nildram.net...

of

handling,

when

Sometimes goto's can be handy, to jump out of a few nested loops inside a function, where a break doesn't handle the situation. As long as it fits within one page... but I honestly can't remember the last time I used it. Once a year perhaps. Similar to 'continue', that's another one that I don't use often. Less than goto ;)

Hi all,

Sorry for asking stupid question: Will C compilers generate same code for "break" and "goto" ?

e.g. // using break for (i=0;i

Maybe. Maybe not. It varies depending on the rest of the program. The third answer is more likely. It's off-topic here, in any case. You might ask on a newsgroup which deals with you particular compiler, but don't be surprised if you get the same answers.

Sorry - wrong newsgroup. It's not necessarily off-topic here. The rest of my answer stands, though.