home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!mcsun!fuug!demos!kiae!glas!demos!microsoft.com!jimad
- From: jimad@microsoft.com
- Newsgroups: comp.lang.c++
- Date: 17 Jul 92 23:42 MDT
- Subject: Re: Committee Members -> What do you th
- Sender: Notesfile to Usenet Gateway <notes@glas.apc.org>
- Message-ID: <1992Jul17.194202.14981@microsoft>
- References: <710560778snx@whizbang.wariat.org>
- Nf-ID: #R:710560778snx@whizbang.wariat.org:639459369:1992Jul17.194202.14981@microsoft:-1529294247:001:8413
- Nf-From: microsoft.com!jimad Jul 17 23:42:00 1992
- Lines: 162
-
-
- In article <1992Jul15.144839.18494@sco.COM> paul@sco.COM (Paul Jackson) writes:
- |By George, I think he's got it! A standard is NOT meant to be a perfect
- |definition of a language that will stand unchanged for eternity, it is meant
- |to be a checkpoint of "current" practice that allows programmers who care to
- |write maximally portable code (note that these two features often conflict
- |which is why standards have implementation defined and undefined behaviour).
- |I put current in quotation marks since it is expected (and thought to be a
- |good thing) that by the time a standard actually finishes wending its way
- |through the system the current state of the art will already have passed it
- |by.
-
- Your definition of what a "standard" "is" flies in the face of the reality
- of the ANSI-C++ committees actions. In some cases, for example exceptions,
- they have ignored existing implementations and chosen to require something
- new different and not implemented in any compilers. In other cases, such
- as templates, they have decided to standardize on something that compilers
- had not only not yet implemented, but which have not to this day been
- even half-specified. Thus compiler-implementors rush to support templates,
- knowing not what they are suppose to implement, with the result that
- each compiler claims they have templates, but it is virtually impossible
- to write a meaningful template class that will work on various compilers.
- In other cases the committee is soliciting "standard" class library
- designs invented out of whole cloth -- classes for which there is no
- implementation anywhere. In other cases, such as name space, the committee
- decided that existing implementations didn't have it right and they'd just
- redesign the whole thing ....
-
- .... So, I don't disagree with you're idea of what a "standard" SHOULD
- be -- in which case ANSI-C++ should just have been "2.1" BUT given that
- the ANSI-C++ effort IN NO WAY corresponds to your definition of what a
- "standard" should be, then you argument cannot stand as an argument against
- "fixing" the current erroneous rationale for special case language
- prohibiting operator.().
-
- |A large number of C vendors (I suspect almost all) provide a compiler which
- |supports several dialects of the C language. One of these (usually not the
- |default) is a strict Ansi C dialect, another is usually an "extended"
- |version of the standard Ansi C dialect. The Ansi C dialect is maximally
- |portable, the extended environment is generally "richer" and has more
- |"features". In a few years, people will again get together and decide which
- |set of features are sufficiently useful to be worth incorporating into the
- |new standard for the language and a new standard will emerge.
-
- In a few years the ANSI-C++ committee will be [at best] just wrapping up
- the proposed ANSI-C++ standard. The standard will then go through several
- years of public review before ratification. The standard will then require
- several more years before compiler vendors really bring their compilers into
- conformance. This is nothing new -- simply review the history of ANSI-C and
- you can see how the ANSI-C++ process will progress! Again, you are describing a
- process VERY DIFFERENT from the actual actions of the ANSI-C++ committee, thus
- your statement have no basis in reality as an argument against operator.()
-
- |Getting back to operator dot, it may or may not make it into this (or any
- |future) standard. If "almost everybody" implements it, or "almost everybody"
- |demands it or "almost everybody" agrees that it is a good idea then it will
- |"almost certainly" make it in. If not, the chances are lower.
-
- On the contrary "almost everybody" will have no say in this matter, as
- history has already shown. On the contrary, a couple people on the
- extensions committee will either support the idea, or talk it down, and
- that will be sufficient to get it on, or keep it off, the floor of the
- committee whole for a vote.
-
- |Personally, I feel that it is just not too important an issue one way or
- |another. Its a fairly minor piece of syntactic sugar that has reasonably
- |minor benefits and costs. Since my personal prejudices are against making
- |extensions to the language I'm against adding operator . but I hardly feel
- |that it is a "make or break" issue.
-
- Operator.() is only necessary if one is interested in having complete
- and safe "smart pointer", "smart reference", "smart array", "reference
- counting" classes etc. If you aren't interested in these things, if
- you aren't interested in making "smart" classes by using templates, etc,
- then you are not interested in operator.(). You probably aren't interested
- in unary operator&(), unary operator->(), unary operator*() EITHER --
- but THOSE things ARE in the language already. So the idea that the language
- should be left in error, and unorthogonal, just because you aren't interested
- in any of these "smart" things is not an argument.
-
- Personally, *I* couldn't care less if anyone bothers to fix some of the
- nuances of the name space problems in C++ -- because I'M NEVER going to
- make use of those nuances. Does it thereby follow that NO committee member
- should "fix" the name space problems?
-
- Further:
-
- This issue has been discussed dozens of times before. OPERATOR.() IS NOT
- A LANGUAGE EXTENSION -- IT IS A LANGUAGE REDUCTION -- IT IS A REMOVAL OF
- AN ERRONEOUS AND UNNECESSARY PIECE OF SPECIAL CASE LANGUAGE IN THE SPEC.
-
- Please -- for the NTH time -- Please read ARM page 330:
-
- "The reason for disallowing the overloading of ., .*, and :: is that
- they already have a predefined meaning for objects of any class as their
- first operand."
-
- Followed by:
-
- "The predefined meaning of the operators =, (unary) &, and , (comma)
- applied to class objects may be changed."
-
- Again summarizing:
-
- Operator.() can't be overloaded because it has predefined meaning.
-
- Operator&() CAN be overloaded even though it has predefined meaning.
-
- This is plain and simple a language design bug. The rationale is
- irrational.
-
- Some committee members simply say "who cares, we the committee members
- do not have to act rational."
-
- Which is a true statement, but it is not a rationale. If the committee membes
- insist on standardizing on bugs, there is nothing the rest of us can do
- about the situation -- except point out the stupidity of such actions.
-
- MY suggested solution to the bug is simply to remove the erroneous and
- unnecessary special case language in the spec. In which case operator.()
- works "just like" the other operators, in particular "just like" operator->().
- This makes operator.() UNARY NOT BINARY. Some people continue to fail to
- understand that a UNARY operator CANNOT depend on something that IS NOT one of
- its parameters, and that conversely that an operator that depends on TWO
- parameters IS a BINARY operator. Thus if whether or not an overloaded operator.
- is invoked in preference to a built-in operator. depends on the RHS of
- the . , in addition to the LHS of the dot, then people MUST BE talking about
- a BINARY operator.(). If one COULD write a BINARY operator.() THEN AND ONLY
- THEN could we talk about situations where built-in operator. is invoked in
- some situations, and overloaded operator. is invoked in other situations
- DEPENDING ON THE RHS.
-
- BUT
-
- If people insist on making operator.() BINARY because they continue to
- insist on SELECTING between built-in operator.() and overloaded operator.()
- based on NOT ONLY the LHS, BUT ALSO the RHS, then I ask these people, please
- tell me what the type of the second parameter to BINARY operator.() IS ????
-
- ANSWER:
-
- The RHS of a BINARY operator.() MUST BE a "reference to member"
-
- BUT
-
- The C++ language does not contain a concept of "reference to member" thus
- no such binary operator.() COULD BE specified! Because you cannot declare
- the type of the second parameter.
-
- THEREFORE:
-
- I do not propose a binary operator.() because no such beast is possible
- in the C++ language. Please stop asking me for it. Please stop using
- it as a bogus argument against allowing unary operator.() to be overloaded
- JUST LIKE OPERATOR->().
-
- If YOU still believe that binary operator.() should be in the language then
- YOU convince the committee to include "references to members" in the language.
- ONLY THEN is a binary operator.() possible. AND THEN, both unary and binary
- operator->() and operator.() become possible JUST LIKE unary and binary
- operator&() are today possible.
-
-