home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / cplus / 12714 < prev    next >
Encoding:
Text File  |  1992-08-20  |  2.6 KB  |  70 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!mcsun!Germany.EU.net!unidus.rz.uni-duesseldorf.de!lannert.rz.uni-duesseldorf.de!TSOS
  3. From: TSOS@uni-duesseldorf.de (Detlef Lannert)
  4. Subject: Re: Tiny proposal for named loops.
  5. Message-ID: <TSOS.61.714395736@uni-duesseldorf.de>
  6. Sender: news@unidus.rz.uni-duesseldorf.de
  7. Organization: Universitaetsrechenzentrum, Heinrich-Heine-Universitaet, Duesseldorf
  8. References: <aldavi01.714376080@starbase.spd.louisville.edu>
  9. Date: Fri, 21 Aug 1992 11:15:36 GMT
  10. Lines: 58
  11.  
  12. In article <aldavi01.714376080@starbase.spd.louisville.edu> aldavi01@starbase.spd.louisville.edu (Arlie Davis) writes:
  13.  
  14. >Since the language is still open to improvements, even those which relate to
  15. >the more C-oriented personality of C++, I'd like to suggest the addition
  16. >of named loops.  The syntax would not break any existing code at all.
  17. >An identifier would be placed just after the "for", "while", "do", or even
  18. >"if" keyword.  This keyword could be used just after "break" or "continue",
  19. >to specify exactly which loop to break or continue.
  20. >
  21. >Example: [deleted for bandwidth's sake]
  22. >
  23. >This would eliminate the need for some state variables used with switches,
  24. >which would make code more readable, and more block-oriented.
  25.  
  26. I like your idea. It could certainly make C[++] code safer
  27. and more legible. There shouldn't be any syntactical problem
  28. with
  29.  
  30.      if [<id>] (<expression>) <statement>
  31.      switch [<id>] (<expression>) <statement>
  32.      while [<id>] (<expression>) <statement>
  33.      do <statement> while [<id>] (<expression>) ;
  34.      for [<id>] (...;...;...) <statement>
  35.  
  36. A "break <id>;" statement would be useful for the "switch"
  37. construct as well as for "while", "do...while", and "for",
  38. as would the "continue <id>;" for the repetitive statements.
  39.  
  40. For the "if", however, there would be no use in assigning
  41. any identification because it does not constitute any blocks
  42. by itself and "continue" or "break" is not applicable.
  43.  
  44. Talking about blocks: Have there been any discussions about
  45. a possible assignment of identifications to blocks? Something
  46. like
  47.  
  48.      {<block-id>
  49.         ...
  50.      <block-id>}
  51.  
  52. instead of just
  53.  
  54.      {
  55.         ...
  56.      }
  57.  
  58. could improve the legibility of C[++] programs and help
  59. localize errors. (A compiler error message should be
  60. generated whenever the block-id of the closing } doesn't
  61. match that of the opening {.) Of course this feature would
  62. have to be optional.
  63.  
  64. I apologize if this suggestion has been discussed before;
  65. otherwise I'd like to hear your comments (and suggestions
  66. with regard to a possible syntax).
  67. --
  68. Detlef Lannert      DC3EK      E-Mail: tsos@rz.uni-duesseldorf.de
  69. "Ab morgen wird gearbeitet."
  70.