home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / cplus / 16342 < prev    next >
Encoding:
Text File  |  1992-11-15  |  3.0 KB  |  69 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!uwm.edu!linac!att!cbnewsc!cbfsb!cbnewsg.cb.att.com!nh
  3. From: nh@cbnewsg.cb.att.com (nicholas.hounsome)
  4. Subject: Re: Proposal - enhancement for switch statement.
  5. Message-ID: <1992Nov16.093252.14843@cbfsb.cb.att.com>
  6. Sender: news@cbfsb.cb.att.com
  7. Organization: AT&T
  8. References: <BxsHtz.8qJ@sti.com>
  9. Date: Mon, 16 Nov 1992 09:32:52 GMT
  10. Lines: 57
  11.  
  12. From article <BxsHtz.8qJ@sti.com>, by dgreen@sti.com (Dan R. Greening):
  13. > mcgrant@rascals.stanford.edu (Michael C. Grant) wrote:
  14. >>In article <1992Nov15.190830.11622@cssc-syd.tansu.com.au>
  15. >>pete@cssc-syd.tansu.com.au (Peter Alexander Merel) writes:
  16. >>> [switch on any type using == proposal]
  17. >>>  Any chance?
  18. >>
  19. >>I doubt it... Even before C++ came along, switch statements could not
  20. >>handle floats, strings, structures, etc. Sure, a switch statement could
  21. >>be turned into a set of if-then-else statements, but it isn't because
  22. >>it usually is best turned into a jump table.
  23. > 
  24. > Smart compilers should put it into a series of jump tables and do binary
  25. > search to identify the correct jump table.
  26. > 
  27. > The obvious rhetorical question is "why not require SwitchType to have
  28. > a well-ordering relation using operator< and operator==?".  They you could
  29. > at least do the binary search part instead of a sequence of "=="
  30. > operations.
  31. > 
  32. > But the rhetoric is just that:  I'd prefer to keep it simple, and leave
  33. > switch alone.
  34. > 
  35. > The reason is pretty simple: you as the programmer know your data much
  36. > better than the compiler.  If you are going to use expensive operations,
  37. > like a series of categorizing "==" operator calls, it seems like you 
  38. > should tailor your "switch" to the data.  The compiler can't do that.
  39. > -- 
  40. > ____
  41. > \  /Dan Greening    Software Transformation   1601 Saratoga-Sunnyvale Rd, #100
  42. >  \/dgreen@sti.com   (408) 973-8081 x313       Cupertino, CA 95014
  43.  
  44. Most switches I have seen are so small that the overhead of range checking
  45. and the possibility of having to have several tables make the whole thing a 
  46. waste of time. 
  47.  
  48. I haven't checked what my sun compiler does but in the past when I checked
  49. output from other compilers I found that they just implemented switches as
  50. if-then-else anyway.
  51.  
  52. I find that switch statements tend to be much larger than if-then-else -
  53. for some reason people seem less inclined to use subsidiary functions in switches  than
  54. in if-then-else. I have no idea why this should be so.
  55.  
  56. I find that having break for both loops and switches means that I have
  57. to create loop exit variables which I hate - I would much rather write
  58. ... if( c == 'q' ) break; than case 'q': quit = TRUE; break;
  59.  
  60. In this day and age we should expect compilers to recogize a sequence
  61. of i-then-else which can be implemented as a jump table. The register
  62. qualifier is now universaly unnecessary - the switch statement should
  63. be as well.
  64.  
  65. If you use classes extensively there is no need for switch because
  66. you cannot create jump tables which was its original raison d'etre.
  67.  
  68. Nick Hounsome
  69.