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 :-).