Xref: utzoo misc.misc:6011 comp.misc:5998
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ukma!uflorida!novavax!twwells!bill
From: bill@twwells.uucp (T. William Wells)
Newsgroups: misc.misc,comp.misc
Subject: Re: The "evil" GOTO (Was: 25 Years of BASIC)
Message-ID: <905@twwells.uucp>
Date: 6 May 89 20:08:47 GMT
References: <1814@ubu.warwick.UUCP> <13113@lanl.gov>
Reply-To: bill@twwells.UUCP (T. William Wells)
Organization: None, Ft. Lauderdale
Lines: 80
Summary:
Expires:
Sender:
Followup-To:
Distribution:
Keywords:

In article <13113@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
: This does not mean that I oppose GOTOs in a programming language.  In fact,
: there _are_ situations in which GOTO is the most readible and efficient
: means of flow control.  Consider the situation in which two branches of
: a conditional merge again:
:
:       if (cond1) {
:          [...A...]   /* lots of code */
:          goto LABEL;}
:       else if (cond2) {
: LABEL:   [...B...]   /* lots more code */
:       }
:
: After executing sequence 'A', the rest of the action for 'cond1' is identical
: to the action for 'cond2'.  The suggested "structured" fixes to this sequence
: include:
:    1) put sequence 'B' in a separate procedure and call it from both places
:
:    2) duplicate sequence 'b' in both places
:
:    3) set a flag variable to hold the condition that 'B' needs to be
:       executed, and put 'B' after the original 'if' sequence enclosed
:       in another conditional.
:
: The problem with 1) is that it introduces a speed penalties due to the
: procedure call - not efficient.

Agreed. Until the amount of code overwhelms the function call
overhead.

:                                  Solution 2) imposes a code space penalty
: as well as making code maintenance difficult (you must always remember to
: update _both_ versions of 'B').

Only half true. Many (most?) optimizers will recognize that the two
code sequences are identical and put the branch where you would
expect.

:                                  Solution 3) imposes a speed penalty for
: setting and testing the flag, a space penalty for the extra variable and
: the code to manipulate it, and it is _less_ readible than the version
: already given above!

Damn straight!

: This conditional-merge problem is one of the only two places where I still
: use GOTO in my programs - the other case is the classic error-exit from
: deep within a nested structure (exception handling, if available, would
: satisfy this requirement).

Be aware that a *single* goto in a function can cause many optimizers
to do nothing for the function. The reason for this is that many of
the better optimization techniques depend on the program having a
particular control structure and transforming an arbitrary program
into one that is acceptable is a hairy task.

: Unfortunately, the above construct is illegal in many "structured"
: programming languages (including - of all things - Fortran).  They seem
: to feel that jumping into a compound statement from the outside is
: bad practice.  Yet, I run into this case all the time (even on very short
: programs (<1000 lines) I usually run into this at least once).  And there
: is no "structured" way around it!

Me, I just live with the possible code duplication; the maintenance
headache is minor. By the time the code is large enough to make both
considerations less than minor, the function call overhead has become
trivial.

: Note: I always make a distinction between well structured programs and
: well "structured" programs.  The later are those which conform to the
: anti-GOTO religion without regard to the actual quality of the code
: itself.  A well "structured" program is often a very badly structured
: one.

Some of the worst structured programs I've seen have been written in
Modula 2. Some people think that merely following the structured
programming rules relieves them from the responsibility to think.

---
Bill                            { uunet | novavax } !twwells!bill