home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / cplus / 11202 < prev    next >
Encoding:
Text File  |  1992-07-20  |  3.8 KB  |  110 lines
  1. Path: sparky!uunet!synaptx!synaptics.com!daveg
  2. From: daveg@synaptics.com (Dave Gillespie)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: boolean (was: Re: typedef vs enum)
  5. Message-ID: <DAVEG.92Jul20220553@synaptx.synaptics.com>
  6. Date: 21 Jul 92 05:05:52 GMT
  7. References: <DOUGM.92Jul19222728@titan.cs.rice.edu>
  8. Sender: daveg@synaptx.Synaptics.Com
  9. Organization: Synaptics, Inc., San Jose, CA
  10. Lines: 97
  11. In-reply-to: dougm@titan.cs.rice.edu's message of 20 Jul 92 04:27:28 GMT
  12.  
  13. In article <DOUGM.92Jul19222728@titan.cs.rice.edu> dougm@titan.cs.rice.edu (Doug Moore) writes:
  14. Andrew>     if (t!=0) cout << "Balderdash!\n";
  15. > 
  16. > You are right.  I was rash.
  17. > I am stung by your balderdash.
  18. > But if one bang just won't do,
  19. > Let's instead just make it two.
  20. > 
  21. >   In other words, try to find an anomaly with literals t!! and f!!.
  22.  
  23. [insert poetry here to taste]
  24.  
  25. If you define "t!!" as a "t" token followed by two "!" tokens, using
  26. the existing C++ lexical rules, then you still have the same sort of
  27. problem:  "if (t!!==2)" cannot be scanned properly (not left-to-right,
  28. anyway).
  29.  
  30. If you define "t!!" as a single token, may the fleas of a thousand
  31. camels, well, you get the idea.  :-)
  32.  
  33. Let's do away with t!! and f!! altogether:  The expressions !!1 and
  34. !!0 are just as simple, and we get them for free.  I find them easier
  35. to tell apart at a glance, too.
  36.  
  37.  
  38. Under "advantages," you might list the ability of a class to define
  39. "operator boole()" conversions instead of/as well as "operator int()".
  40. Many classes define misleading "int" conversions when they really
  41. want only a boolean conversion.
  42.  
  43. I worried for a moment about boolean bit-fields, but then I remembered
  44. that C++ allows bit-fields of any integral type (unlike ANSI C).
  45. That's good.
  46.  
  47. Is it possible for a template "Array<boole>" to define itself
  48. naturally as a packed bit vector?  That would be pretty cool.
  49.  
  50. Does there need to be any mention of "signed", "unsigned", "short",
  51. and "long" as applied to "boole"?  (Specifically, that all of these
  52. are disallowed?)
  53.  
  54.  
  55. One thing I worry about with this proposal is the ability to write
  56. programs to work equally well with pre- and post-"boole" C++.  I don't
  57. know what preprocessor name is being used to identify ANSI C++, but
  58. suppose it's __STDCPLUS__.  I thought about putting a simple
  59.  
  60. #ifndef __STDCPLUS__
  61. typedef int boole;
  62. // or: #define boole int
  63. #endif
  64.  
  65. at the front of my program, but that's not enough:  There will be
  66. situations where in ANSI C++ I want to overload like this,
  67.  
  68. class Foo {
  69.   void bar(int x) { ... }
  70.   void bar(boole x) { ... }
  71.   operator int() { ... }
  72.   operator boole() { ... }
  73. };
  74.  
  75. the typedef trick won't work because now we have multiple conflicting
  76. declarations when we use an old-style compiler.  Every one of these
  77. would also have to be guarded by #ifdef's.
  78.  
  79. What can be done to ease the transition from current C++ to C++
  80. with booleans?
  81.  
  82.  
  83. I like the way the boolean type solves all the ills of the "&&=/||="
  84. proposals.  There is no issue of normalizing the values to 0/1, because
  85. we know we're working with booleans already.  Very nice.
  86.  
  87. > The behavior of an expression of the form E1 &&= E2 is equivalent to
  88. > E1 ? (E1=(E2)) : f!, except that E1 is evaluated only once.
  89.  
  90. Any reason you wrote it that way instead of as "E1 = E1 && E2"?  The
  91. only way I can see that this would make a difference is if "E1" is a
  92. volatile variable.  Is that rare case worth sacrificing the elegance
  93. of defining "E1 <op>= E2" as "E1 = E1 <op> E2" always?
  94.  
  95.  
  96. There is a minor typo in section 1 of your proposal:
  97.  
  98. > When arithmetic or pointer types appear in a
  99. > context that requires a boolean value, standard logical conversions
  100. > are applied to convert nonzero arithmetic and nonnull pointer types to
  101. > f!.
  102.  
  103. This should be t! (or, possibly, !!1).
  104.  
  105.                                 -- Dave
  106. --
  107. Dave Gillespie
  108.   daveg@synaptics.com, uunet!synaptx!daveg
  109.   or: daveg@csvax.cs.caltech.edu
  110.