Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!gatech!bloom-beacon!think!ames!ptsfa!ihnp4!cuae2!killer!jfh From: jfh@killer.UUCP (The Beach Bum) Newsgroups: comp.lang.c Subject: Re: goto's in C: an opinion... Message-ID: <1182@killer.UUCP> Date: Thu, 23-Jul-87 15:48:05 EDT Article-I.D.: killer.1182 Posted: Thu Jul 23 15:48:05 1987 Date-Received: Sat, 25-Jul-87 14:00:43 EDT References: <3289@bigburd.PRC.Unisys.COM> <7571@beta.UUCP> <3435@oberon.USC.EDU> <3567@oberon.USC.EDU> Organization: The Unix(tm) Connection, Dallas, Texas Lines: 93 Keywords: C, goto, style Summary: blah blah blah ... In article <3567@oberon.USC.EDU>, mlinar@poisson.usc.edu (Mitch Mlinar) writes: > 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 I find when writing programs as finite state machines, that the code is somewhat less readable _but_ almost always infinitely more correct. Usually some big switch statement and a table of state changes (anyone who has written a push down automaton knows just how big these tables can get for a grammar like C or pascal ...) does the trick. The actual code is so simple and the tables can be generated almost automatically (unless you use yacc, in which case it can be generated automatically :-) That, in this humble programmer's opinion, is the highest form of structure. A couple dozen lines of code, and an array with a couple thousand entries ... The points I am trying to make are: 1). Readablity affects maintainablity. 2). Structure affects maintainablity. 3). Design affects maintainablity. I _always_ document my goto's (about 1 or 2 percent of my statements) with a `come from' that describes the state and condition of the program when execution reaches that point in the code. This does two things: 1). Improves the readablity. 2). (generally) Improves the design. The second is a result of having to think of what conditions you want flow control to reach the goto. Consider the following fragment: (Keep in mind that I would never actually write this piece of code ...) OpenFile (FileName, FilePointer, FileBuffer, RecordSize) char *FileName; FILE **FilePointer; char **FileBuffer; int RecordSize; { *FilePointer = NULL; *FileBuffer = NULL; if (access (FileName, 0) == -1) goto ErrorExit; if ((*FilePointer = fopen (FileName, "r")) == NULL) goto ErrorExit; if ((*FileBuffer = malloc (RecordSize)) == NULL) goto ErrorExit; /* Maybe some more processing, and jumps to ErrorExit */ return (1); /* ErrorExit - handle all known forms of errors ... * You know how you got here? Right? You know what to do? Right? */ ErrorExit: if (*FilePointer) fclose (*FilePointer); if (*FileBuffer) fclose (*FileBuffer); return (0); } Any questions? This may not be `structured', ala University Pascal style structured, but I'd rather see this than some nasty collection of deeply nested if-then-else-if-...'s or 3 or 4 `error handlers' that look just like the code in ErrorExit with a few minor changes. - John. -- John F. Haugh II HECI Exploration Co. Inc. UUCP: ...!ihnp4!killer!jfh 11910 Greenville Ave, Suite 600 "Don't Have an Oil Well?" Dallas, TX. 75243 " ... Then Buy One!" (214) 231-0993