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: <3567@oberon.USC.EDU> Date: Tue, 21-Jul-87 23:18:08 EDT Article-I.D.: oberon.3567 Posted: Tue Jul 21 23:18:08 1987 Date-Received: Thu, 23-Jul-87 07:18:09 EDT References: <3289@bigburd.PRC.Unisys.COM> <7571@beta.UUCP> <3435@oberon.USC.EDU> <8321@utzoo.UUCP> Sender: nobody@oberon.USC.EDU Reply-To: mlinar@poisson.usc.edu.UUCP (Mitch Mlinar) Organization: University of Southern California, Los Angeles Lines: 17 Keywords: C, goto, style In article <8321@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >> 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"... > >Try putting it in a table-driven form before you reject goto-less solutions. >Usually still more readable, seldom significantly slower if done carefully. ^^^^^^^^^^^^^^^^^^^^^^^^^^^ Yes, a table-driven form is goto-free, but I am not sure it is *really* readable. (I admit it is probably more readable than the goto solution.) The main point I was trying to make (and supported by your statement), is that the code is NOT always faster when done right. Personally, I prefer code that is maintainable, even if there is some speed loss. (To say that correct code is ALWAYS faster and/or smaller is a fallacy.) -Mitch