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

  1. Path: sparky!uunet!mcsun!fuug!demos!kiae!glas!demos!microsoft.com!jimad
  2. From: jimad@microsoft.com
  3. Newsgroups: comp.lang.c++
  4. Date: 17 Jul 92 23:42 MDT
  5. Subject: Re: Committee Members -> What do you th
  6. Sender: Notesfile to Usenet Gateway <notes@glas.apc.org>
  7. Message-ID: <1992Jul17.194202.14981@microsoft>
  8. References: <710560778snx@whizbang.wariat.org>
  9. Nf-ID: #R:710560778snx@whizbang.wariat.org:639459369:1992Jul17.194202.14981@microsoft:-1529294247:001:8413
  10. Nf-From: microsoft.com!jimad    Jul 17 23:42:00 1992
  11. Lines: 162
  12.  
  13.  
  14. In article <1992Jul15.144839.18494@sco.COM> paul@sco.COM (Paul Jackson) writes:
  15. |By George, I think he's got it! A standard is NOT meant to be a perfect
  16. |definition of a language that will stand unchanged for eternity, it is meant
  17. |to be a checkpoint of "current" practice that allows programmers who care to
  18. |write maximally portable code (note that these two features often conflict
  19. |which is why standards have implementation defined and undefined behaviour).
  20. |I put current in quotation marks since it is expected (and thought to be a
  21. |good thing) that by the time a standard actually finishes wending its way
  22. |through the system the current state of the art will already have passed it
  23. |by.
  24.  
  25. Your definition of what a "standard" "is" flies in the face of the reality
  26. of the ANSI-C++ committees actions.  In some cases, for example exceptions,
  27. they have ignored existing implementations and chosen to require something
  28. new different and not implemented in any compilers.  In other cases, such
  29. as templates, they have decided to standardize on something that compilers
  30. had not only not yet implemented, but which have not to this day been
  31. even half-specified.  Thus compiler-implementors rush to support templates,
  32. knowing not what they are suppose to implement, with the result that
  33. each compiler claims they have templates, but it is virtually impossible
  34. to write a meaningful template class that will work on various compilers.
  35. In other cases the committee is soliciting "standard" class library 
  36. designs invented out of whole cloth -- classes for which there is no
  37. implementation anywhere.  In other cases, such as name space, the committee
  38. decided that existing implementations didn't have it right and they'd just
  39. redesign the whole thing ....
  40.  
  41. .... So, I don't disagree with you're idea of what a "standard" SHOULD
  42. be -- in which case ANSI-C++ should just have been "2.1"  BUT  given that
  43. the ANSI-C++ effort IN NO WAY corresponds to your definition of what a 
  44. "standard" should be, then you argument cannot stand as an argument against
  45. "fixing" the current erroneous rationale for special case language 
  46. prohibiting operator.().
  47.  
  48. |A large number of C vendors (I suspect almost all) provide a compiler which
  49. |supports several dialects of the C language. One of these (usually not the
  50. |default) is a strict Ansi C dialect, another is usually an "extended"
  51. |version of the standard Ansi C dialect. The Ansi C dialect is maximally
  52. |portable, the extended environment is generally "richer" and has more
  53. |"features". In a few years, people will again get together and decide which
  54. |set of features are sufficiently useful to be worth incorporating into the
  55. |new standard for the language and a new standard will emerge.
  56.  
  57. In a few years the ANSI-C++ committee will be [at best] just wrapping up
  58. the proposed ANSI-C++ standard.  The standard will then go through several
  59. years of public review before ratification.  The standard will then require
  60. several more years before compiler vendors really bring their compilers into
  61. conformance.  This is nothing new -- simply review the history of ANSI-C and
  62. you can see how the ANSI-C++ process will progress!  Again, you are describing a 
  63. process VERY DIFFERENT from the actual actions of the ANSI-C++ committee, thus
  64. your statement have no basis in reality as an argument against operator.()
  65.  
  66. |Getting back to operator dot, it may or may not make it into this (or any
  67. |future) standard. If "almost everybody" implements it, or "almost everybody"
  68. |demands it or "almost everybody" agrees that it is a good idea then it will
  69. |"almost certainly" make it in. If not, the chances are lower.
  70.  
  71. On the contrary "almost everybody" will have no say in this matter, as
  72. history has already shown.  On the contrary, a couple people on the 
  73. extensions committee will either support the idea, or talk it down, and
  74. that will be sufficient to get it on, or keep it off, the floor of the
  75. committee whole for a vote.
  76.  
  77. |Personally, I feel that it is just not too important an issue one way or
  78. |another. Its a fairly minor piece of syntactic sugar that has reasonably
  79. |minor benefits and costs. Since my personal prejudices are against making
  80. |extensions to the language I'm against adding operator . but I hardly feel
  81. |that it is a "make or break" issue.
  82.  
  83. Operator.() is only necessary if one is interested in having complete
  84. and safe "smart pointer", "smart reference", "smart array", "reference
  85. counting" classes etc.  If you aren't interested in these things, if
  86. you aren't interested in making "smart" classes by using templates, etc,
  87. then you are not interested in operator.().  You probably aren't interested
  88. in unary operator&(), unary operator->(), unary operator*() EITHER --
  89. but THOSE things ARE in the language already.  So the idea that the language
  90. should be left in error, and unorthogonal, just because you aren't interested
  91. in any of these "smart" things is not an argument.
  92.  
  93. Personally, *I* couldn't care less if anyone bothers to fix some of the 
  94. nuances of the name space problems in C++ -- because I'M NEVER going to
  95. make use of those nuances.  Does it thereby follow that NO committee member
  96. should "fix" the name space problems?
  97.  
  98. Further:
  99.  
  100. This issue has been discussed dozens of times before.  OPERATOR.() IS NOT
  101. A LANGUAGE EXTENSION -- IT IS A LANGUAGE REDUCTION -- IT IS A REMOVAL OF
  102. AN ERRONEOUS AND UNNECESSARY PIECE OF SPECIAL CASE LANGUAGE IN THE SPEC.
  103.  
  104. Please -- for the NTH time -- Please read ARM  page 330:
  105.  
  106. "The reason for disallowing the overloading of ., .*, and ::  is that
  107.  they already have a predefined meaning for objects of any class as their
  108.  first operand."
  109.  
  110. Followed by:
  111.  
  112. "The predefined meaning of the operators =, (unary) &, and , (comma)
  113.  applied to class objects may be changed."
  114.  
  115. Again summarizing:
  116.  
  117. Operator.() can't be overloaded because it has predefined meaning.
  118.  
  119. Operator&() CAN be overloaded even though it has predefined meaning.
  120.  
  121. This is plain and simple a language design bug.  The rationale is
  122. irrational.
  123.  
  124. Some committee members simply say "who cares, we the committee members 
  125. do not have to act rational."
  126.  
  127. Which is a true statement, but it is not a rationale.  If the committee membes
  128. insist on standardizing on bugs, there is nothing the rest of us can do
  129. about the situation -- except point out the stupidity of such actions.
  130.  
  131. MY suggested solution to the bug is simply to remove the erroneous and 
  132. unnecessary special case language in the spec.  In which case operator.()
  133. works "just like" the other operators, in particular "just like" operator->().
  134. This makes operator.() UNARY NOT BINARY.  Some people continue to fail to 
  135. understand that a UNARY operator CANNOT depend on something that IS NOT one of 
  136. its parameters, and that conversely that an operator that depends on TWO 
  137. parameters IS a BINARY operator.  Thus if whether or not an overloaded operator.
  138. is invoked in preference to a built-in operator. depends on the RHS of
  139. the . , in addition to the LHS of the dot, then people MUST BE talking about
  140. a BINARY operator.().  If one COULD write a BINARY operator.() THEN AND ONLY
  141. THEN could we talk about situations where built-in operator. is invoked in
  142. some situations, and overloaded operator. is invoked in other situations
  143. DEPENDING ON THE RHS.
  144.  
  145. BUT
  146.  
  147. If people insist on making operator.() BINARY because they continue to
  148. insist on SELECTING between built-in operator.() and overloaded operator.()
  149. based on NOT ONLY the LHS, BUT ALSO the RHS, then I ask these people, please
  150. tell me what the type of the second parameter to BINARY operator.() IS ????
  151.  
  152. ANSWER:
  153.  
  154. The RHS of a BINARY operator.() MUST BE a "reference to member"
  155.  
  156. BUT
  157.  
  158. The C++ language does not contain a concept of "reference to member" thus
  159. no such binary operator.() COULD BE specified!  Because you cannot declare
  160. the type of the second parameter.
  161.  
  162. THEREFORE:
  163.  
  164. I do not propose a binary operator.() because no such beast is possible
  165. in the C++ language.  Please stop asking me for it.  Please stop using
  166. it as a bogus argument against allowing unary operator.() to be overloaded
  167. JUST LIKE OPERATOR->().
  168.  
  169. If YOU still believe that binary operator.() should be in the language then
  170. YOU convince the committee to include "references to members" in the language.
  171. ONLY THEN is a binary operator.() possible.  AND THEN, both unary and binary
  172. operator->() and operator.() become possible JUST LIKE unary and binary 
  173. operator&() are today possible.
  174.  
  175.