Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!gatech!bloom-beacon!oberon!poisson.usc.edu!mlinar
From: mlinar@poisson.usc.edu (Mitch Mlinar)
Newsgroups: comp.lang.c
Subject: Re: goto's in C: an opinion...
Message-ID: <3435@oberon.USC.EDU>
Date: Sat, 18-Jul-87 02:09:31 EDT
Article-I.D.: oberon.3435
Posted: Sat Jul 18 02:09:31 1987
Date-Received: Sat, 18-Jul-87 19:11:51 EDT
References: <3289@bigburd.PRC.Unisys.COM> <7571@beta.UUCP>
Sender: nobody@oberon.USC.EDU
Reply-To: mlinar@poisson.usc.edu.UUCP
Organization: University of Southern California, Los Angeles
Lines: 95
Keywords: C, goto, style

In article <7571@beta.UUCP> hwe@beta.UUCP (Skip Egdorf) writes:
>In article <3289@bigburd.PRC.Unisys.COM>, weiss@bigburd.PRC.Unisys.COM (Tom Weiss) writes:
>> 
>> Since now appears to be the time to express opinions about
>> style/clarity, I would like to address my own pet peeve: the goto
>> statement.
>
>I love your comments Tom, now just be a bit more assertive...
>
>> 
>> There are very few legitimate uses for the goto statement,
>
>  There are NO legitimate uses for the goto statement...
>

Hmmmm.   Methinks I smells a fanatic ...

>> 
>> Since C provides the break statement to break out of a loop, the
>> continue statement to jump back to the top of a loop, the return
>> statement to immediately exit a function, and access to system calls
>> (e.g. exit) that can terminate execution in error handling functions,
>> there are few 'legitimate' uses for goto.  The only one that
>> immediately comes to mind is breaking directly out of a
>> multiply-nested control structure.
>
>And if such a structure is used, it can ALWAYS be improved by removing
>some of the structure to a sub-function.
>

which also clearly increases the code size (even if only a little),
but let's read on

>   more efficient, and shorter in both source and object form. EVERY
>   case was a triple win, with no loss. I have never found a case
>   where someone could provide me with a goto'ed code, and I could not
>   improve it in all three areas. Anyone reading this who sends me some

Given even your rough example, you have not proven anything to me yet.

>   Goto lovers find it fairly simple to come up with code fragments that
>   require extra state variables or extra levels of procedure call to
>   improve. My removal of gotos sometimes required my return to the
>   functional specification of the system and a complete re-implementation.
>   (and yes, I re-implemented as little as necessary, so that this did
>   not skew the results too badly. I do believe that the re-implementation
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
What does this mean?  I could take this to mean the code is HARDER to read,
has LONGER source, or just plain wrong.

>
>In any language that supports a complete set of structured constructs,
>there is NO NEED for a goto, and the statement should be removed from
>the language!
>

Well, Skip, you have not given me anything concrete to work on.  Before you
get all steamed up, let me say I agree with you *in principle* and I also
strive quite hard to keep goto's out of the C code (and am over 95%
successful, if I had to take a stab at the actual stats).  However, there are
some things I think you over-dramatized:

  (1) (Sub)programs without GOTOs are NOT always more readable.

  (2) Similarly, STRUCTURED code is not always easier to read.  I have seen
some pretty STRANGE structures which are "curable" (I know you hate the use
here) by the addition of one GOTO.  I have watched programmers beat themselves
up on this one...

  (3) THERE IS *NO* GENERALIZATION THAT CAN BE MADE REGARDING CODE SIZE.  I
can give you HUNDREDS of examples (and bury your mail system :-) that
clearly show a GOTO produces less code size, and I can give you a hundred more
where STRUCTURE clearly produces the smaller code.  It is dependent upon the
function being implemented.  (Please show me how a structure made more
readable by moving a piece into a subfunction can produce SMALLER or FASTER
code.  At BEST, there is a CALL/RETURN opcode set and associated delay.)


Again, I *agree* with the principle, but be realistic!  I always strive to
dump GOTOs in favor of structures REALIZING that code size may NOT
go down, but that MAINTAINABILITY increases.  I often "kick back" code which
I feel has unnecessary GOTOs to the originator; since most of the time they
are NOT needed.  But to declare that GOTOs are NEVER acceptable is
pure horse-puckey.  (I am not sure the "grand master" was in favor of
stamping them out altogether, I *believe* he felt the way I do - it is too
easy to use GOTOs to get the code working rather than planning and 
structuring the program correctly - "GOTO disease" - and should only be
used WHERE THE CODE WARRANTS IT.)

There is a nice class of decision trees which can NEVER be implemented smaller
in a structure and and appear MESSIER when in a structure (to me anyway)
versus just a couple labels and GOTOs to "help the structure out".  I would be
happy to drop just one of these on the net if you have trouble believing me.

-Mitch