home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / cplus / 11587 < prev    next >
Encoding:
Text File  |  1992-07-26  |  4.5 KB  |  102 lines

  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!munnari.oz.au!cs.mu.OZ.AU!mundil.cs.mu.OZ.AU!fjh
  3. From: fjh@mundil.cs.mu.OZ.AU (Fergus James HENDERSON)
  4. Subject: Re: New C++ type: boole
  5. Message-ID: <9220914.11530@mulga.cs.mu.OZ.AU>
  6. Sender: news@cs.mu.OZ.AU
  7. Organization: Computer Science, University of Melbourne, Australia
  8. References: <DOUGM.92Jul26200316@titan.cs.rice.edu>
  9. Date: Mon, 27 Jul 1992 04:44:30 GMT
  10. Lines: 90
  11.  
  12. The following is actually from Deviasse Robert N <a228devi@cdf.toronto.edu>.
  13. I am posting it for him, since he does not have write access to the net.
  14. Disclaimer: if you don't like it, blame him! :-)
  15.  
  16.     Fergus.
  17.  
  18. ========================== PROPOSAL FOLLOWS =============================
  19.  
  20. Actually there is a general way of adding a boole type without breaking any
  21. C++ code. Every DOS compiler I've used (and a few UNIX ones) already give
  22. warning for code such as "if (ch=getchar()) /*...*/;". Such warnings could
  23. easiliy be made manditory in the standard, or the standard could reserve
  24. a pragma that does this type of checking, though the implementation may
  25. choose not to implement it. Market pressure would probably force most
  26. compilers (the ones that do no implement this feature yet) to implement
  27. the macros anyway, although they need not. This alone would go a long
  28. way towards providing the benefits of a boolean type "universally". However,
  29. there are other cases that would be nice to fix. What most of us would like 
  30. is protection from the following type of situation:
  31.    void f(int x) { /*...*/ }
  32.    void f(BOOL y) { /*...*/ }
  33.  
  34.    f(a==b);  /* OOPS, wrong f() called!!! */
  35.  
  36. The simplest way to avoid this situation is if BOOL were declared "int",
  37. since the second f() would be illegal. This is really not so significant
  38. since it is very rare for both function overloadings to be intentionally
  39. needed. However, if BOOL==int then we lose a lot of the nice properties
  40. of BOOL being an enum, such as the need for explicit casts. What we need
  41. is an enum that protects us from unintentional mistakes like the above.
  42.  
  43. Suppose we modify the enum construct to the following form
  44.  
  45.    enum <integral_type> <id> { id < = value > { , id < = value > } ;
  46.    ----                      -      -           -      -         - -
  47.  
  48.    where an underlined word is a keyword or punctuation,
  49.        < A >  means that A is optional
  50.        { A }  means that A is repeated 0 or more times
  51.  
  52. The semantics of this new enum would be that during overload resolution of
  53. a function, the enum would conflict with integral_type. However, no automatic
  54. conversion between enum and integral_type would occur beyond what is
  55. presently allowed in C++. Also, to make this type of enum more useful, the
  56. enum would have exactly the same size as the integral_type and have it's
  57. enumerations represented in the type of the integral_type. Thus one could
  58. use these enumerated types in structures that required enumerated types of
  59. the given size.
  60.  
  61. So that if we define:
  62.      enum int BOOL { FALSE, TRUE };
  63.  
  64. then the following produce errors:
  65.    void f(int x) { /*...*/ }
  66.    void f(BOOL y) { /*...*/ }   /* error: conflicts with f(int) */
  67.  
  68. similarly
  69.    void f(BOOL y) { /*...*/ }
  70.    f(BOOL(a==b));
  71. would require a cast.
  72.  
  73. It would be nice if we had such an enumerated type in the standard library,
  74. perhaps in <boolean.h> of the following form.
  75.    enum int Boole { boole_false, boole_true };
  76. This would reduce the number of different flavours of boolean types that
  77. programmers currently define.
  78.  
  79.  
  80. I think that most people would like to have a boolean type in C++, although
  81. most people have resigned themselves to thinking that boolean types
  82. cannot easily be added to C++.
  83.  
  84. I thing this is a fair workable compromise that allows the programmer
  85. to protect him/her self without turning the semantics of C++ inside-out.
  86. True, the above is a "humpty-dumpty" enum, but then what's wrong with
  87. Humpty-Dumpty, many computer science books quote from Lewis Carol :-)
  88.  
  89. ------
  90. I don't have write-access to the net, although I have no problem reading
  91. from the net.
  92.  
  93. BTW, I'm not going to write to the ANSI committee to extend the C++
  94. language to add this type of enum, I'm far too busy. If someone else
  95. wants to pick up this proposal, then be my guest. Otherwise, please
  96. post this proposal to /dev/nul.
  97.  
  98. /----------------------------------+------------------------------------------\
  99. | Robert N. Deviasse               |"If we have to re-invent the wheel,       |
  100. | EMAIL: a228devi@cdf.toronto.edu  |  can we at least make it round this time"|
  101. +----------------------------------+------------------------------------------/
  102.