Path: utzoo!mnetor!uunet!husc6!bloom-beacon!mit-eddie!rutgers!iuvax!pur-ee!uiucdcs!uiucdcsb!kenny
From: kenny@uiucdcsb.cs.uiuc.edu
Newsgroups: comp.lang.c
Subject: Re: Put your code... (was Re: gotos
Message-ID: <165600045@uiucdcsb>
Date: 26 Apr 88 01:33:00 GMT
References: <2597@ttrdc.UUCP>
Lines: 71
Nf-ID: #R:ttrdc.UUCP:2597:uiucdcsb:165600045:000:3421
Nf-From: uiucdcsb.cs.uiuc.edu!kenny    Apr 25 20:33:00 1988


[Part 7. Conclusions]

As we have seen, programming tools that have come into general use
since 1974, together with the larger memories now available on
computers, render most of the arguments in Knuth's paper obsolete.
There is still a use for the _goto_ statement in code generated by
preprocessors and compilers (for such things as finite-state machines
and the elimination of recursive calls).  The _goto_ statement is also
still useful for `panic exit' conditions.  These uses alone justify
leaving the _goto_ statement in the language.

The advent of _break_ and _continue_ make the use of _goto_ in double
decisions and double-exit loops superfluous, for the most part.  The
small minority of cases where the loop cannot be expressed with these
newer constructs are probably better handled with repeated tests or
auxiliary variables.  Cases where performance considerations preclude
using the auxiliary variables or repeating the tests are rare.  In
this vanishing minority of cases, a _goto_ may again be an acceptable
evil -- but the code should be profiled, and the performance gain
calculated, before any such optimization is attempted. (It is of note
that modern compilers are beginning to be able to do this sort of
optimization for the user, by using techniques of data-flow analysis
to delete redundant tests.)

The advent of _ungetc_, and of finite-state scanner generators, makes
the use of _goto_ much less attractive in text-scanning applications.
EXAMPLE 4 is unacceptable given today's programming practice.

The availability of pointers and generalized call-by-reference in
high-level languages means that _goto_ is no longer necessary to
describe the control structures for performing parallel operations on
different data.  EXAMPLE 5 is much better handled by use of a pointer.

I leave the discussion of alternative control structures (not
involving _goto_) for multiple-exit constructs to others; the
suggestions that Knuth makes in this regard may be valid, but are
still sufficiently immature to consider incorporating them in a
standard language such as `C'.

In short, use of _goto_ directly by a programmer is most likely
excusable only where the _goto_ represents a panic exit condition.
There are a few other cases where compilers and preprocessors can
generate _goto_s freely.  All other uses are to be disparaged.

References

[Ashc71] Ashcroft, Edward, and Zohar Manna.  ``The translation of
`goto' program to `while' programs.''  Information Processing 71:
Proc. IFIP Congress 71, Lubljana, Jugoslavia, pp. 250-255.

[Boehm66] Boehm, C., and G. Jacopini.  ``Flow diagrams, Turing
machines, and languages with only two formation rules.'' CACM 9:5
(1966) 366-371.

[Farr76] Farrow, R., K. Kennedy, and L. Zucconi.  ``Graph grammars and
global program flow analysis.'' Proc. 17th Annual IEEE Symposium on
Foundations of Computer Science, Houston, Texas, 1975.

[Kenn81] Kennedy, Ken.  ``A survey of data flow analysis techniques,''
in _Program Flow Analysis: Theory and applications_, Steven S.
Muchnuck and Neil D. Jones, eds., Englewood Cliffs, New Jersey:
Prentice-Hall, 1981, pp. 5-54.

[Lesk75] Lesk, Michael E.  ``Lex -- a lexical analyzer generator.''
CSTR 39, Murray Hill, New Jersey: Bell Laboratories, 1975.

[Wolm??] Wolman, Barry E. ``Reducing the cost of procedure activation
in block structured languages.''  Circa 1976, publication information
unavailable at this time.