home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / cplus / 11581 < prev    next >
Encoding:
Internet Message Format  |  1992-07-26  |  4.0 KB

  1. Path: sparky!uunet!synaptx!synaptics.com!daveg
  2. From: daveg@synaptics.com (Dave Gillespie)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: New C++ type: boole
  5. Message-ID: <DAVEG.92Jul26170054@synaptx.synaptics.com>
  6. Date: 27 Jul 92 00:00:54 GMT
  7. References: <DOUGM.92Jul25234214@titan.cs.rice.edu>
  8. Sender: daveg@synaptx.Synaptics.Com
  9. Organization: Synaptics, Inc., San Jose, CA
  10. Lines: 75
  11. In-reply-to: dougm@titan.cs.rice.edu's message of 26 Jul 92 05:42:14 GMT
  12.  
  13. In article <DOUGM.92Jul25234214@titan.cs.rice.edu> dougm@titan.cs.rice.edu (Doug Moore) writes:
  14. > Dave> If you define "t!!" as a single token, may the fleas of a thousand
  15. > Dave> camels, well, you get the idea.  :-)
  16. > Dave> Let's do away with t!! and f!! altogether:  The expressions !!1 and
  17. > Dave> !!0 are just as simple, and we get them for free.  I find them easier
  18. > Dave> to tell apart at a glance, too.
  19. > Although the needs of the writers of scanners was not my primary
  20. > concern when I proposed t!! and f!!, I can agree that they might make
  21. > their lives a little difficult, and might make everyone's scanners a
  22. > little slower.
  23.  
  24. I wasn't as concerned with the difficulty of writing the scanner as
  25. much as with the aesthetics of the language.  Making a C++ token which
  26. was a mixture of letters and operator symbols would be confusing and
  27. awkward.  Surely there must be something prettier, something more
  28. consistent with the rest of the language, that we could use.
  29.  
  30. > On the other hand, I do want boole literals and not circumlocutions
  31. > like !!0 and !!1.  I could live with 0t and 0f, and I don't think the
  32. > scanner writers would wish upon me an infestation of dromedary vermin
  33. > for inventing those two particular symbols.  Would they?
  34.  
  35. Is "!!0" such a circumlocution?  Consider the constant "-2.3".  We
  36. read and write this as a simple number, but the C++ grammar considers
  37. it a unary "-" operator with the unsigned literal "2.3".  C++ has no
  38. token for -2.3, so it expresses it as a simple, canonical expression
  39. that generates the value.  !!0 and !!1 are just the same, albeit
  40. somewhat less obviously canonical.
  41.  
  42. Your "0t" and "0f" are not bad, but I don't like "0t"'s implication
  43. that the numeric value of the literal is zero.  "int(0t) == 1" would
  44. be very confusing.  How about "0b" and "1b", analogous to "0L" and
  45. "1L"?  Since "boole" is an integral type, it makes sense for it to
  46. follow the conventions of integer literals, i.e., an integer value
  47. followed by a type suffix letter.
  48.  
  49. > Dave> What can be done to ease the transition from current C++ to C++
  50. > Dave> with booleans?
  51. > Well, one could probably cook up a class boole that one could
  52. > conditionally include if using an unenlightened compiler.  That
  53. > wouldn't solve everything.  Anytime you add to the language, programs
  54. > that use the new features can't be compiled with the old compilers.  I
  55. > can't see a global solution to that.
  56.  
  57. I was concerned that programs written during the transition period
  58. would be forced to work under both systems, and that the most
  59. obvious simulations of "boole" on older compilers would not be
  60. satisfactory.  Maybe a true "boole" class would---I just wanted to
  61. point out that this is an area that deserves careful thought.
  62.  
  63. "Boole" is not simply an addition to the language, since its
  64. presence would change the meanings of existing constructs which
  65. appear in every C++ program.
  66.  
  67. > Dougm> The behavior of an expression of the form E1 &&= E2 is equivalent to
  68. > Dougm> E1 ? (E1=(E2)) : f!, except that E1 is evaluated only once.
  69. > Dave> Any reason you wrote it that way instead of as "E1 = E1 && E2"?
  70. > I wrote it that way to emphasize that in E1 &&= E2 or E1 ||= E2, no
  71. > assignment need take place if E1 has the appropriate value.  That
  72. > is probably sufficiently obvious to go unsaid.
  73.  
  74. As far as I know, the compiler can always delete a useless assignment
  75. unless the variable in question is volatile.  For symmetry's sake,
  76. I prefer to think in terms of "E1 = E1 && E2", myself.
  77.  
  78.                                 -- Dave
  79. --
  80. Dave Gillespie
  81.   daveg@synaptics.com, uunet!synaptx!daveg
  82.   or: daveg@csvax.cs.caltech.edu
  83.