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