home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / cplus / 16334 < prev    next >
Encoding:
Internet Message Format  |  1992-11-15  |  5.1 KB
  1. Xref: sparky comp.lang.c++:16334 comp.std.c++:1569
  2. Newsgroups: comp.lang.c++,comp.std.c++
  3. Path: sparky!uunet!ukma!wupost!usc!elroy.jpl.nasa.gov!news.claremont.edu!jarthur.claremont.edu!dfoster
  4. From: dfoster@jarthur.claremont.edu (Derek R. Foster)
  5. Subject: Re: Proposal - enhancement for switch statement.
  6. Message-ID: <1992Nov16.004558.9855@muddcs.claremont.edu>
  7. Sender: news@muddcs.claremont.edu (The News System)
  8. Organization: Harvey Mudd College, Claremont, CA 91711
  9. Date: Mon, 16 Nov 1992 00:45:58 GMT
  10. Lines: 103
  11.  
  12. In article <MCGRANT.92Nov15132747@rascals.stanford.edu> mcgrant@rascals.stanford.edu (Michael C. Grant) writes:
  13. >In article <1992Nov15.190830.11622@cssc-syd.tansu.com.au>
  14. >pete@cssc-syd.tansu.com.au (Peter Alexander Merel) writes:
  15. >   Before I describe what occurred to me, yes folks I know that a switch is not
  16. >   as useful as a virtual function.
  17. >   But what I'd like for a snippet I'm working on at the moment would be for
  18. >   switch to use operator== rather than relying on conversion to int, so that 
  19. >   I could use it to test cases on objects rather than building an industrial 
  20. >   strength if statement. 
  21. ...
  22. >   Any chance?
  23. >
  24. >I doubt it... Even before C++ came along, switch statements could not
  25. >handle floats, strings, structures, etc. Sure, a switch statement could
  26. >be turned into a set of if-then-else statements, but it isn't because
  27. >it usually is best turned into a jump table.
  28.  
  29. Personally, I would like to see a few more changes made to the 'switch'
  30. statement (in my opinion, one of the ugliest warts on the face of the
  31. C language, and regrettably C++ also.)
  32.  
  33. I wouldn't advise actually getting rid of the 'switch' statement (it is
  34. needed for backwards compatibility), but instead creating a (somewhat) 
  35. parallel statement, called, say, 'switchc'. The purposes of 'switchc' would be:
  36.  
  37.   1) Remove the requirement for a 'break' after each statement (the accidental
  38.      omission of which is the cause of a ridiculously large number of errors
  39.      within C programs.) Make a 'break' the default, rather than fallthrough
  40.      being the default. Add a 'fallthrough' keyword (or extend the
  41.      meaning of the 'continue' keyword perhaps?) to still allow programmers
  42.      to use fallthrough in those rare occasions for which it is necessary/
  43.      desirable.
  44.  
  45.   2) Allow multiple labels for each 'case' statement, and extend the case
  46.      statement to allow ranges and multiple arguments (as in Pascal.) This
  47.      avoids the excessively verbose lists of 'case' statements that are
  48.      necessary in C to represent ranges of values.
  49.  
  50. as per Peter's suggestion, we could easily add...
  51.  
  52.   3) for class-typed switching variables, we could require that 'switchc' 
  53.      use operator == and a simple linear search to work its way down the
  54.      list. (yes, this is possibly inefficient. It is, however, extremely
  55.      clear code which is easy to read.) In the case of non-class-typed
  56.      switching variables, the compiler is allowed to use a jump table,
  57.      binary search, or whatever seems appropriate.
  58.   4) in implementing 3, we could allow, for class typed variables, the
  59.      switch labels to be any data type for which operator == with the
  60.      given class type is defined. For instance, char *'s, floating point
  61.      values, (references to const objects?,) etc.
  62.  
  63.      thus, code like:
  64.        int x;
  65.        switch(x)
  66.        {
  67.          case '1': case '2': case '3': case '4': case '5': case '6':
  68.          case '7': case '8': case '9': case '0': 
  69.            cout << "x is a digit\n";
  70.          case 'A':
  71.            cout << "x is a digit or the letter 'A'\n"; 
  72.            break;
  73.          default:
  74.            cout << "x is not a digit or the letter 'A'\n";
  75.        }
  76.      could also be written:
  77.        switchc(x)
  78.        {
  79.          case 0...9: cout << "x is a digit\n"; fallthrough;
  80.          case 'A':   cout << "x is a digit or the letter 'A'\n;
  81.          default:    cout << "x is not a digit or the letter 'A'\n";
  82.        }
  83.  
  84.     also, consider the possibility of code like:
  85.  
  86.       String command;
  87.       cin >> command;
  88.       switchc(command)
  89.       {
  90.         case "DIR":          do_directory();
  91.         case "VIEW":         do_view();
  92.         case "QUIT","EXIT":  do_exit();
  93.         default: cerr << "Unknown command!";
  94.       }
  95.     If the above code is written using 'if's, it is a) much harder to
  96.     read, b) much harder to understand (the reader may not immediately
  97.     see the overall structure), and c) more error-prone (it is possible to
  98.     get mismatched 'else's, etc. which will compile fine, but not do
  99.     what they're supposed to.
  100.  
  101.     I would LOVE to see the addition of something like this to the language.
  102.     Control flow in many of my programs would be vastly simplified, and I
  103.     think the number of errors I would make would be substantially smaller.
  104.  
  105. >I wouldn't object to such an addition in principle, except for the fact
  106. >that it's unnecessary (a big objection for sure).
  107.  
  108. C++ is unnecessary. It's there because it makes programs easier to understand,
  109. and because it reduces programming errors. Those seem like good reasons to me.
  110. I think this extension satisfies those goals as well.
  111.  
  112. >Michael C. Ggrant
  113.  
  114. Derek Riippa Foster
  115.