From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,86fd56abf3579c34 X-Google-Attributes: gid103376,public From: stt@spock.camb.inmet.com (Tucker Taft) Subject: Re: State machines and Goto's (was Re: Should internet support software be written in Ada?) Date: 1995/04/07 Message-ID: #1/1 X-Deja-AN: 100070376 sender: news@inmet.camb.inmet.com (USENET news) x-nntp-posting-host: spock.camb.inmet.com references: <3m0nv5$67l@theopolis.orl.mmc.com> organization: Intermetrics, Inc. newsgroups: comp.lang.ada Date: 1995-04-07T00:00:00+00:00 List-Id: Theodore Dennison (dennison@escmail.orl.mmc.com) wrote: : dewar@cs.nyu.edu (Robert Dewar) wrote: : >Here is the basic issue with finite state machines. A normal picture : >of a finite state machine is a spaghetti diagram with circles for : >states and arrows for transitions. One reason to prefer case statements over gotos for implementing a finite state machine is that there is no danger of forgetting the "goto" at the "end" of a state's code. Using gotos instead of a "case" statement opens up the programmer to the same kind of bug as the notorious "missing break" in C/C++ switch statements. You might just flow through to the state that happened to follow in the text of the program, without intending to. E.g.: goto Initial_State; <> blah; blah; -- oops, I forgot the goto. <> ... Versus: State : State_Enum := Initial_State; Next_State : State_Enum; begin loop Next_State := Uninitialized_State; case State is when State_1 => blah; blah; -- oops, I forgot to set Next_State when State_2 => ... end case; if Next_State = Uninitialized_State then Put_Line("Next_State not set"); Put_Line("Previous state is " & State_Enum'Image(State)); raise Program_Error; end if; State := Next_State; -- Advance to next state end loop; Of course, you could also see the goto-based approach's capability of "flowing through" as a nice opportunity for optimization (that is presumably why "break;" is not the default in C/C++ switch statements). However, I believe few would argue at this point with 20/20 hindsight (including the most die-hard C programmer), that the C/C++ default of "fall through" between switch alternatives was the right choice. : Which is why people today tend to design using structure charts. : >Please be clear, I am not saying that anyone who completely avoids : >gotos is incompetenmt, not at all. I am saying that it is wrong to think : >that it is appropriate to visit this absolute rule on competent : >programmers. : I have now worked under 3 different Ada coding standards. Every one : of them had a "no goto's" rule. Since I'm currently editing our next : coding standard, perhaps someone could suggest a replacement rule? It : should be very specific about what allowable and unallowable goto's : are. We need something that our software quality folks can enforce. : The rule can make NO assumptions about the competency of the programmer, : as we won't find out the truth on that matter until it is too late. Here is a half-serious ;-} suggestion: How about requiring the programmer to write a short paragraph in the comments, on why the goto was the most appropriate solution for the given problem? Require that the paragraph be no less than 20 words, and no more than 100 words long. The net effect would be to create a sufficient incentive that the programmer would have to think hard before using a goto. : T.E.D. (structured programming mafioso) -Tucker Taft stt@inmet.com Intermetrics, Inc.