Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!ut-sally!husc6!cca!g-rh
From: g-rh@cca.CCA.COM (Richard Harter)
Newsgroups: comp.lang.c
Subject: Re: goto's in C: an opinion...
Message-ID: <17905@cca.CCA.COM>
Date: Sun, 19-Jul-87 13:57:44 EDT
Article-I.D.: cca.17905
Posted: Sun Jul 19 13:57:44 1987
Date-Received: Sun, 19-Jul-87 20:45:22 EDT
References: <3289@bigburd.PRC.Unisys.COM> <322@dvm.UUCP>
Reply-To: g-rh@CCA.CCA.COM.UUCP (Richard Harter)
Organization: Computer Corp. of America, Cambridge, MA
Lines: 65

In article <322@dvm.UUCP> hymie@dvm.UUCP (Hyman Rosen) writes:
>> ... goto [that] was used to jump
>>forward into the middle of an if/else construct. ...
>
>That's about the only time that I've had to use goto's. (I usually handle
>jumping out of a couple of loops by an extra test.) The case that particularly
>comes to mind is in converting a string to float, which I've had to do a
>number of times (in situations where atof() or sscanf() were not options).
>Handling the cases of no digits before the decimal point or no digits after
>the decimal point always seems to require either a duplication of code, or
>a branch into one of the cases of an if-else statement, and I always choose
>the goto. On the other hand, another programmer I work with insists that this
>is an abomination, and would outrightly ban jumps into blocks from C. Note
>that in C++ such branches are forbidden when they would cause a declaration
>of an item with a constructor to be bypassed.

	Different folks, different strokes.  It's hard for me to think of
a way to code this particular problem where you have a conceivable reason
for wanting to jump into a if-else block.  It might be interesting if you
posted a sketch of the approach that occurs to you naturally.

	In theory I count myself among the defenders of the goto.  In
practice I use them very rarely if the language at hand has the constructs
I need.  For example in a 50,000 line PL/I program I used exactly one,
to transfer out of an on-condition block.  In a 50,000  line C program
I used six, all of which were used to do cleanup in error handling.
I avoid the need to escape from deep levels of nesting by never using
deep levels of nesting. 

	On the theoretical side, control constructs can be arranged
in a heirarchy of strengths:

0	if-then-else/while
1	forever loop
2	simple goto
3	procedure call/return
4	computed goto

Any program can be written using the level 0 constructs.

Any program can be written using the level 0 constructs.  Each level is
stronger than the one below it.  I.e. for any level we can find programs
which will be more expensive in use of resources (space, time) if the
constructs of that level are not used.

This is one reason why no-goto advocates often say that one should use
procedures to avoid code replication -- in effect, they are proposing
that one should replace the weaker construct (the goto) by a stronger
construct (the procedure call/return).  Unfortunately the procedure
call mechanism is not a panacea; the problems are (a) cost of invocation,
and (b) transfer of information to the called procedure.

Strikingly enough, the most powerful programming construct possible,
the computed goto, is available in C (and most alternative languages)
in the form of the switch/case construct.  In theory, and in practice,
problems with complex level 0 constructs can be resolved and simplified
by recasting them in the form of switch/case constructs.  I grant that
the switch/case construct can be just as obscure as the code it replaces.
Nonetheless it has been my experience that complicated logic problems
are most conveniently handled by thinking of the problem in terms of
a finite-state machine and a list of states and actions.
-- 

Richard Harter, SMDS Inc. [Disclaimers not permitted by company policy.]
			  [I set company policy.]