|
Funny thing about GOTOs ...
Everyone thinks they are bad, and I agree that in most cases there is a better way to handle the flow of execution.
On the other hand, every assembly language jockey, myself included, uses JMP all the time. Yet, this is no different than a GOTO - in fact that is exactly what it is. But I never hear anyone raising hell about using JMP in assembly code - in fact you couldn't write much assembly code without it.
Strange world at times I think.
Mitch & Murray (from downtown)
Monday, October 13, 2003
I think people like to declare things as extremes. People usually love exceptions or hate them.
I think they have their place. I also think that the things that generate runtime exceptions (null pointers and such) will be a problem even without exceptions. How would you handle reporting that if you didn't have exceptions? At least java's model lets you try.
And am I the only one who routinely uses gotos to jump to cleanup code in complex pure-C routines, as a sort of "poor mans exception"?
Everything has its place. Even if nobody knows what it is 8-}
Mike Swieton
Monday, October 13, 2003
Mitch & Murray (from downtown) said:
"... GOTOs ... are bad, and ... in most cases there is a better way to handle the flow of execution ... [but] ... assembly language ... uses JMP all the time." [elisions subtracted]
Welllllll,
that's because a complete "virtual machine" (i.e. the model envisioned by designers of the higher-level language) can be devised with semantics that exclude "transfer of control" (as proven in 1966 by B&J), but it has been found impractical (and/or inefficient) to build hardware that way.
The "translator" (including compiler/interpreter, code-generator, etc.) is free to use available machine resources to the compiler to simulate the semantics of the higher-level language (which might also exclude other machine features, such as halt, interrupt, memory-mapping, context-switch, etc.)
An assembler, however, must provide opcodes for every feature that is supported by the machine architecture.
Bruce A. Martin
Monday, October 13, 2003
Even Djikstra backtracked and said too much ado was made over his "Goto's Considered harmful" article.
If you think about, break and continue are really just goto's with a implicit label. Also, in VB6 goto's are used all the time for error handling.
The main argument against goto is that if you pepper your code with it, it will become indeciferable and hard to maintain.
As an aside, I've always thought HOWTO's reminded me of spaghetti code. You start off reading on one subject, don't understand part of it, jump to related HOWTO, repeat ad infinatum.
Nick
Monday, October 13, 2003
JMP is allowable in assembly because there aren't any good alternatives. You don't have WHILE loop constructs or IF/ELSE constructs, so a conditional jump followed by an unconditional JMP is a natural way to implement that type of flow.
But it has been mathematically proven that as long as a language has IF/ELSE and loop constructs that allow premature exits, GOTO is never necessary.
T. Norman
Monday, October 13, 2003
To backup the latter statement, take a look at the Gofer programming language (not to be confused with the protocol). It's a formal approach which totally omits procedures, thus every program consists of nested function declarations and logical/mathematical operators.
Johnny Bravo
Monday, October 13, 2003
Nick.
<quote>
If you think about, break and continue are really just goto's with a implicit label. Also, in VB6 goto's are used all the time for error handling.
</quote>
Most VB programmers would make a distinction between straight GOTO and On Error Goto. While On Error Goto has the word 'Goto' in it, I find it more helpful to think of it as VB's mechanism for SEH (Structured Exception Handling). Conceptually, it is quite different to a straight GOTO.
Seeya
Matthew
Monday, October 13, 2003
"JMP is allowable in assembly because there aren't any good alternatives. You don't have WHILE loop constructs or IF/ELSE constructs, so a conditional jump followed by an unconditional JMP is a natural way to implement that type of flow."
Depends on the assembler. Some implement higher level constructs such as loops and if tests. Of course they end up as JMP instructions in the machine code, but you don't have to write them.
Sum Dum Gai
Monday, October 13, 2003
Without GOTOs I would have never gotten into programming...
10 PRINT "I AM GREAT!"
20 GOTO 10
RUN
"I AM GREAT!"
"I AM GREAT!"
"I AM GREAT!"
...
Stress
Tuesday, October 14, 2003
The banishment of GOTOs is consistent with the "McDonalds approach to making 'chefs' " that is far too common in this industry - GOTOs can be used by the uninformed to introduce errors in their code, and can confuse the incapable when glancing over someone else's code; therefore they need to be removed, and the language needs to be distilled down to just a couple of basic, failsafe, dummy-level instruction.
I worked in one organization once where such a McDonald's Chef advocated such standards, including the abolishment of GOTOs, generously providing a sample of my code. This code was a piece of state logic where the cleanest, most logical approach was the institution of a goto statement at one point to do an intra-procedure jump. Upon being challenged, they then provided a modified version now imbued with a dozen plus lines of horribly convoluted logic to do what the goto once did. Why? Gotos are evil to McDonald's Chefs!
Dennis Forbes
Tuesday, October 14, 2003
Very true. Unconditional intra-procedure jumps are occasionally the best and cleanest way to implement complex execution paths, such as jumping out of nested loops.
Incidentally that's why a newly designed OOP language like C# still has the goto statement. It's amusing that fanatical goto haters apparently all think they're smarter than Anders Heijlsberg...
Chris Nahr
Tuesday, October 14, 2003
Most VB routines that I write have an ERROR_HANDLER label and an EXIT_POINT label at the end. Since the positions are consistent in every single routine, the argument that it makes the code hard to follow really doesn't apply.
Arbitrary Goto Labels in the middle of a routine, however, are another matter entirely.
Ran Whittle
Tuesday, October 14, 2003
I hardly want to engage in a classic, and thoroughly pointless, debate about the merits of goto, however your wording caught my attention: Do you define any use of a goto that differs from your own as "arbitrary"? If a software professionally analyzed a requirement, and developed a solution where a goto, an unbelievably obvious and predictable mechanism of flow control, made the most sense, to you this is arbitrary?
Dennis Forbes
Tuesday, October 14, 2003
One of the biggest problems with GOTO is that it is unclear to the casual reader where the GOTO is jumping to. It is not even clear which direction they are jumping. My point is that consistency of application can largely resolve that issue. Arbitrary (and perhaps that is not the best word, but it fits) applications of GOTO would be those where the GOTO destination is not intuitive to the casual reader.
In VB we do not have an 'Exit sub but clean up first' command, nor do we have a 'catch unexpected errors' command. We use GOTOs as stand-ins for these unmet needs (this is fairly standard). I confess that it is a bit awkward, but I do believe that consistency of label and location can minimize that awkwardness.
The majority of times when I have seen VB software writers 'professionally examine a requirement and use a GOTO' (apart from the abovementioned examples) it is either (1) because they need to exit nested loops, or (2) because they are validating inputs, the inputs failed validation, and they want to jump back to the place where the input is entered so that they can re-prompt the user. (Of course there are other applications.) Neither of these are particularly clear GOTO applications IMHO.
Ran Whittle
Tuesday, October 14, 2003
Thats why INTERCAL has a COME FROM instead of a GOTO. This sorts out the jump stratergy completely :-)
Johnny Moondog
Wednesday, October 22, 2003
 Recent Topics
Fog Creek Home
| 
