Xref: utzoo misc.misc:5943 comp.misc:5953
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!tank!eecae!cps3xx!rang
From: rang@cpsin3.cps.msu.edu (Anton Rang)
Newsgroups: misc.misc,comp.misc
Subject: Re: The "evil" GOTO (Was: 25 Years of BASIC)
Message-ID: <2861@cps3xx.UUCP>
Date: 5 May 89 16:22:59 GMT
References: <1791@ubu.warwick.UUCP> <1436@onion.reading.ac.uk> <1814@ubu.warwick.UUCP> <24044@agate.BERKELEY.EDU>
Sender: usenet@cps3xx.UUCP
Reply-To: rang@cpswh.cps.msu.edu (Anton Rang)
Organization: Michigan State University, Computer Science Dept.
Lines: 47
In-reply-to: ked@garnet.berkeley.edu's message of 5 May 89 02:47:13 GMT

In article <24044@agate.BERKELEY.EDU> ked@garnet.berkeley.edu (Earl H. Kinmonth) writes:

>Since 1979 I have been programming in C. I have written C code into the
>high six-figures (lines of code). There has not been one case where a
>goto seemed appropriate. When I was tempted, reflection and analysis
>convinced me that a goto solution was inappropriate.

  Not one case?  I haven't been programming in C that long, but I've
run into cases where a 'goto' is clearer than any of the other
solutions.  There is usually another way to do it, but often the goto
seems best (especially for exception handling, though not always).
  Partly, this is because I dislike some of C's "features".  Returning
from the middle of a function fred() is "more evil" (IMHO) than making
a label "end_of_fred" and using "goto end_of_fred".  Why?  Because
there is only one entry to and exit from the function (as somebody
else pointed out, this is useful if you're allocating resources etc.)
  Using "break" is OK for small loops, but not good for huge ones.
Why?  You can't tell where the break goes without going through the
loop, balancing "{" and "}".  Also, if you ever move the code with the
break into another loop, you're now breaking from the wrong loop!
Named loops, or labels "end_while_n_loop" avoid this problem.
  Exception handling is the worst problem.  I used to write functions
which had millions of nested if statements, because I had been
thoroughly indoctrinated with "GOTO is EVIL!".  I'd write code that
would be "call function. If success, { call function.  If success, {
call function. [ ad infinitum ] } } " .  Much easier to have a label
at the end of the function to handle it--easier to write, easier to
read, and much easier to change.
  Incidentally, using GOTO in these ways--always to get out of a
structure--doesn't seriously hurt compiler optimization, because you
shouldn't be breaking up basic blocks in the process (jumping into the
middle of a sequence of statements is what's evil, GOTO's not evil).

> Based on substantial experience, I would
>nevertheless suggest that if you are absolutely convinced of the need
>for a goto, that section of the code should really be done in
>assembler.

  Assembler???  Why should I sacrifice readability, and (some)
portability, just because I need (or want) a "goto"?

+---------------------------+------------------------+-------------------+
| Anton Rang (grad student) | "VMS Forever!"         | VOTE on	         |
| Michigan State University | rang@cpswh.cps.msu.edu | rec.music.newage! |
+---------------------------+------------------------+-------------------+
| Send votes for/against rec.music.newage to "rang@cpswh.cps.msu.edu".   |
+---------------------------+------------------------+-------------------+