home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / cplus / 12923 < prev    next >
Encoding:
Internet Message Format  |  1992-08-26  |  1.6 KB
  1. Path: sparky!uunet!stanford.edu!agate!agate!matt
  2. From: matt@physics16.berkeley.edu (Matt Austern)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: GOTO, was: Tiny proposal for na
  5. Date: 26 Aug 92 12:24:22
  6. Organization: Lawrence Berkeley Laboratory (Theoretical Physics Group)
  7. Lines: 20
  8. Message-ID: <MATT.92Aug26122422@physics16.berkeley.edu>
  9. References: <714668024@thor> <6800007@tisdec.tis.tandy.com>
  10.     <1992Aug26.130335.26725@hemlock.cray.com>
  11. Reply-To: matt@physics.berkeley.edu
  12. NNTP-Posting-Host: physics16.berkeley.edu
  13. In-reply-to: dsf@cray.com's message of 26 Aug 92 13:03:35 CDT
  14.  
  15. In article <1992Aug26.130335.26725@hemlock.cray.com> dsf@cray.com (Dan Frankowski) writes:
  16.  
  17. > If one-entry-one-exit is part of a structured programming, then the
  18. > goto is not "just another structured technique."  Note that I did not
  19. > say gotos have no uses.  (I haven't made up my mind yet.  Maybe this
  20. > thread will help me decide.  :-)
  21.  
  22. The classic situation where gotos are generally believed to be useful
  23. is writing a finite-state machine.
  24.  
  25. It seems to me that you could probably do better, though, by defining
  26. some abstract class State, and then deriving the actual states of the
  27. finite-state machine from it; this seems like it might be a more
  28. elegant technique.  (I haven't tried this, though; I'm just
  29. speculating.)
  30. --
  31. Matthew Austern                   Just keep yelling until you attract a
  32. (510) 644-2618                    crowd, then a constituency, a movement, a
  33. austern@lbl.bitnet                faction, an army!  If you don't have any
  34. matt@physics.berkeley.edu         solutions, become a part of the problem!
  35.