Article View: comp.lang.misc
Article #4387Re: GOTO controversy
From: Herman Rubin
Date: Fri, 08 Mar 1996 15:15
Date: Fri, 08 Mar 1996 15:15
56 lines
2984 bytes
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-mailReferences:
<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