Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!columbia!rutgers!clyde!bellcore!faline!sabre!gamma!pyuxp!pyuxe!pyuxf!asg From: asg@pyuxf.UUCP (alan geller) Newsgroups: comp.lang.c Subject: Re: goto's in C: an opinion... Message-ID: <162@pyuxf.UUCP> Date: Fri, 24-Jul-87 14:41:33 EDT Article-I.D.: pyuxf.162 Posted: Fri Jul 24 14:41:33 1987 Date-Received: Sun, 26-Jul-87 04:49:11 EDT References: <3289@bigburd.PRC.Unisys.COM> <7571@beta.UUCP> <1237@ius2.cs.cmu.edu> Organization: Bell Communications Research Lines: 31 Summary: Finite state machines and gotos In article <1237@ius2.cs.cmu.edu>, edw@ius2.cs.cmu.edu.UUCP writes: > > In an article by Skip Egdorf (hwe@beta.UUCP), Skip sez, > > There are NO legitimate uses for the goto statement... > > I sez.. > There is a whole class of problems that map very nicely into goto contructs. > They are simulation of NFAs and DFAs (ie finite state machines). > > States map very nicely to labels and transitions map very nicely into > if (input == ?) goto label. > > The most readable way one can represent the NFA/DFA is through a mesh > of gotos with a diagram of the machine in comments :-). I disagree -- the most readable way to present a finite state machine is with a transition matrix (array), an action matrix (array), and a driver routine that looks like: state = INITIAL_STATE; while (state != ACCEPT_STATE) { input = getInput(); performAction(actionMatrix[state][input]); state = transitionMatrix[state][input]; } or something along those lines. This produces code that is more easily maintained, more compact, and often faster than using a bushel of goto's. Alan Geller {rutgers,princeton}!pyuxp!pyuxf!asg Bellcore, 33 Knightsbridge Rd., Piscataway, N.J. (201)-699-7641 My employers had nothing to do with the above -- unless it's patentable :-).