home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / cplus / 16329 < prev    next >
Encoding:
Text File  |  1992-11-15  |  1.6 KB  |  36 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!stanford.edu!EE.Stanford.EDU!sierra!mcgrant
  3. From: mcgrant@rascals.stanford.edu (Michael C. Grant)
  4. Subject: Re: Proposal - enhancement for switch statement.
  5. In-Reply-To: pete@cssc-syd.tansu.com.au's message of Sun, 15 Nov 1992 19:08:30 GMT
  6. Message-ID: <MCGRANT.92Nov15132747@rascals.stanford.edu>
  7. Sender: usenet@EE.Stanford.EDU (Usenet)
  8. Organization: Information Systems Laboratory, Stanford University
  9. References: <1992Nov15.190830.11622@cssc-syd.tansu.com.au>
  10. Date: 15 Nov 92 13:27:47
  11. Lines: 23
  12.  
  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.    And no, the class in question won't go onto int.
  22.    This should be language compatible with the C usage, and not too hard
  23.    for translaters to do just by translating into the aforementioned 
  24.    industrial if.
  25.    Any chance?
  26.  
  27. I doubt it... Even before C++ came along, switch statements could not
  28. handle floats, strings, structures, etc. Sure, a switch statement could
  29. be turned into a set of if-then-else statements, but it isn't because
  30. it usually is best turned into a jump table.
  31.  
  32. I wouldn't object to such an addition in principle, except for the fact
  33. that it's unnecessary (a big objection for sure).
  34.  
  35. Michael C. Ggrant
  36.