Those are nothing like GOTOs, but model interrupts which are important parts of real machines. I suspect people today don’t learn about them, since for the most part the OS handles them.
Any construct which interrupts flow of control, goes somewhere and does something and then returns, is not a problem for structured code (and in fact often improves it) and has nothing to do with gotos except the letters G and O.
I think it can be argued that some modern programming constructs are actually disguised GOTOs. For example, the “continue” statement placed near the top of a loop indicates that the rest of the loop is to be skipped for that iteration. The code goes back to the the beginning of the loop.
So, while the GOTO has been denigrated and vilified, its effects are still maintained, albeit in a more-supported fashion.
There’s a lot of GOTO work going on under the hood, but a decently high level language will have the basic abstractions implemented to make direct use of GOTO unnecessary. When you look at optimizing compilers or run times, there’s even more GOTO stuff going on (simple example: tail recursion stack flattening). But a programmer who’s not working on a very low level of abstraction (like, writing assembly, implementing some language runtime, or baking some really interesting new concepts in some hypothetical lisp variant) will not need GOTO. Hell, even C doesn’t have a strict GOTO; setjmp/longjmp are stack based.
IIRC you need GOTO to be a Turing Complete language, so its probably a pretty safe bet that every language will produce GOTOs in the assembler output, even if they don’t have explicit ones in the high level language.
But the point is that GOTOs are low level, and probably don’t belong in high level languages anymore then the ability to address registers do, even though there are plenty of high level commands that are “disguised” register manipulation.
True. You can avoid the use of such constructs by using flags - if you find a situation where you actually want to continue, set the flag and don’t do anything if the flag is set during the rest of the loop - but what you wind up with is even worse than using a go to. Pascal had this problem. This was exactly what the orals question I mentioned above was about. But loop exit statements are very constrained as to destination, with labels only necessary if you want to exit from several layers down.
A very safe bet, since you cannot implement the control blocks that are a part of any high level language without them. I include conditional branches as case of gotos. Jumps just change the contents of the program counter - kind of hard to do much without being able to do that.
I could write perfectly beautiful code with just GOTO’s, the issue isn’t the actual function of jumping control to a different portion of code - it’s the overall organization of the code, the number of entries and exits to sections of code, the independence of function, etc.
I’ve been a professional C programmer for 15 years, and I can think of only two cases where I used GOTOs, and both involved cases where performance was paramount:
(1) a very tricky piece of code that was decoding RLE graphics of some sort, which was basically jumping between 6 or 7 FSMs each of which would grab the next bit of data and process it. So basically like 6 or 7 switch statements all in one function, each one with a label before it, with many of the cases being GOTOs to the labels. Could have been one larger level switch statement with a state variable, but that would have been slightly less optimized
(2) a multiply nested loop in which the GOTO was basically break, and only GOTO’d a label directly after the loop
This is exactly what we were trying to teach our assembly language class. We did a fairly good job of it. It isn’t hard once you incorporate it into your programming style. In one quiz section I was teaching I for some reason wrote a recursive factorial program in PDP-11 assembly language on the fly in front of the class. You can’t do that unless you think in terms of high level constructs first.
People used to call programs with lots of gotos spaghetti code. I was working for AT&T when we released our first PC, made by Olivetti. One guy called it the pasta processor, great for running spaghetti code.
I actually remember that article - I was reading Datamation back then.
There was also a set of recommended IBM 360 instructions like this, including my favorite, RPM (Read Programmer’s Mind). I can’t find them with a quick search, though.
Continuation passing style seems to me to have all the disadvantages of goto. It’s inexplicably also extremely popular with functional programmers.
You need unbounded iteration (or recursion) and the ability to control the flow of the program. You don’t need goto to do the latter, and if statement (much more circumscripted than a goto) will work.