home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / cplus / 12890 < prev    next >
Encoding:
Internet Message Format  |  1992-08-25  |  1.3 KB
  1. From: kevinl@tisdec.tis.tandy.com
  2. Date: 25 Aug 92 08:32 CDT
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: GOTO, was: Tiny proposal for na
  5. Message-ID: <6800007@tisdec.tis.tandy.com>
  6. Path: sparky!uunet!haven.umd.edu!darwin.sura.net!convex!news.oc.com!utacfd.uta.edu!trsvax!trsvax!tisdec.tis.tandy.com!kevinl
  7. Nf-ID: #R:thor:714668024:tisdec.tis.tandy.com:6800007:000:819
  8. Nf-From: tisdec.tis.tandy.com!kevinl    Aug 25 08:32:00 1992
  9. References: <714668024@thor>
  10. Lines: 16
  11.  
  12.  
  13.     I have to paritally disagree.  Everytime you add a flag variable,
  14. you are doubling the number of states for your program.  The more states,
  15. the more possible paths, and the more paths, the more possible unforseen
  16. errors (if the paths are not anticipated and tested--something that is
  17. very hard to do).
  18.     For experienced programmers, the goto is a legitamite tactic.
  19. There may not be any cases where a goto is absolutly necessary (I've
  20. heard that there are some, but I have yet to see any), but putting
  21. a goto instead of, say, another function call in a path that is called
  22. 10,000 times each time the program is run, saves massive amounts of
  23. time.
  24.     I agree that programs are generally easier to understand and
  25. debug when there are no goto statements, but, if well documented
  26. gotos are just another structured technique.
  27.  
  28.