🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.lang.misc
Article #4387

Re: GOTO controversy

#4387
From: Herman Rubin
Date: Fri, 08 Mar 1996 15:15
56 lines
2984 bytes
In article <4hlg11$dd7@news1.mnsinc.com>,
Szu-Wen Huang <huang@mnsinc.com> wrote:
>John Noland (sinan@cyberramp.net) wrote:

>[snip]
>:  DON'T use a goto unless it's the only solution to the problem.
>:  You have many alternatives to a goto in your above code. 

>Wrong.  'goto' will never be the only solution.  When the 'goto'
>solution is more elegant than the other choices (which is entirely
>possible), use 'goto'.

I agree that GOTO wo;; mever be the only solution.  One can simulate any
GOTO language in a GOTO-less language.  And what is a switch or case
statement other than a generalization of the Fortran computed GOTO?
BTW, I have come up with a situation where the analog of the Fortran
assigned GOTO (in some places  ASSIGN LOC TO K; in others GOTO K)
would be quite useful in reducing transfers.

>:  A subroutine should have at most one label.

>Arbitrary number.  Does a subroutine with exactly *two* labels
>automatically and magically become unreadable?

I would make it a block.  I have an extremely natural example
of a block where there should be six entry labels.

Many, if not most, mathematical function libraries now have two entries
in the sincos routine.  I would expect a Jacobian elliptic function
routine to have at least six.

>:  All goto's should be above that label in the code.

>Above?  You mean all 'goto's should be forward jumps?  Why?

>:  The label should be in the same code block or at a more outer
>:  nesting level than the goto itself.

>: Your code could be easily reorganized to not use a goto.

>That's the point against using 'goto's.  Realize however that a
>good engineer is usually smarter than blind guidelines.  The
>rules you raised have obvious drawbacks.  Personally, the rule
>I impose upon myself is: "If you use a 'goto', you better have
>a damn good reason for it and be prepared to explain why all
>other constructs make the program uglier."

One of the most important reasons is that the code will run faster.
Sometimes the main cost of the algorithm consistes in processing
the transfers and conditional transfers.  Storing and loading
vlaues which are only needed to indicate where to transfer, and
the use of case or switch statements, with their overhead, can
often be replaced by the use of simple goto instructions.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
hrubin@stat.purdue.edu	 Phone: (317)494-6054	FAX: (317)494-0558
Technical Details
Message-ID: <4hpits$1p1v@b.stat.purdue.edu>
Path: arc1-ca.pugleaf.net!mozo.cc.purdue.edu!not-for-mail
References: <rcshlds.1.000A6705@mailserv.mta.ca> <4grt4e$8fg@goanna.cs.rmit.EDU.AU> <4hl8mt$4po@newshost.cyberramp.net> <4hlg11$dd7@news1.mnsinc.com>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!mozo.cc.purdue.edu!not-for-mail
From: hrubin@b.stat.purdue.edu (Herman Rubin)
Newsgroups: comp.lang.misc,comp.lang.c,comp.lang.pl1
Subject: Re: GOTO controversy
Date: 8 Mar 1996 10:15:08 -0500
Organization: Purdue University Statistics Department
Message-ID: <4hpits$1p1v@b.stat.purdue.edu>
References: <rcshlds.1.000A6705@mailserv.mta.ca> <4grt4e$8fg@goanna.cs.rmit.EDU.AU> <4hl8mt$4po@newshost.cyberramp.net> <4hlg11$dd7@news1.mnsinc.com>
NNTP-Posting-Host: b.stat.purdue.edu