Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!umd5!purdue!decwrl!hplabs!hpl-opus!hpccc!hp-sde!hpfcdc!hpislx!hplvla!hplvly!boyne
From: boyne@hplvly.HP.COM (Art Boyne)
Newsgroups: comp.lang.c
Subject: Re: Re^3: gotos
Message-ID: <3950004@hplvly.HP.COM>
Date: 26 Apr 88 14:52:14 GMT
References: <2606@ttrdc.UUCP>
Organization: HP Loveland Inst Div, CO
Lines: 31

In article <1988Apr24.004842.3251@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes:
# > When faced with multiple occurances of a common section
# > of code, one has four choices (any others?):
# >   1) some sort of subroutine,
# >   2) replicating the code in multiple places,
# >   3) some type of big, ugly conditional statement to
# >      bring together the occurances,
# >   4) goto.
# 
# Remember that there are two separate issues here:  what you write, and the
# code the compiler generates for it.  With modern compilers, the two are
# often quite different.

Some of us don't have the ?luxury? of having *modern* compilers to do all
the optimization/whoop-dee-doo for us.  We are faced with having to use
rather "primitive" compilers that barely can handle constant folding and
register reuse, and generate 2-3x more code that any 1st semester assembly
language student would.  In other words, WYSIWYG.  So the two "separate"
issues are not so separate for us real-world types.

Even if the issues were separate, I tend to disagree that goto, used
appropriately, is less readable, understandable, or supportable than
the other alternatives listed above.  I have to flip pages of a listing
(or rewindow in an editor) to find the subroutine; replicating the code
makes the routines longer than is considered "nice"; and complex conditional
statements can be unintelligible.  And I still have the real-world issues
of code size and execution time to consider.

I stand by my original comments.

Art Boyne,  ...!hplabs!hplvly!boyne