Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!microsoft!jimad From: jimad@microsoft.UUCP (Jim ADCOCK) Newsgroups: comp.lang.c++ Subject: Re: Overloaded operator dot Message-ID: <72913@microsoft.UUCP> Date: 14 Jun 91 18:45:08 GMT References: <41694@ucbvax.BERKELEY.EDU> <5175@lupine.NCD.COM> <1991May27.233113.14550@hal.com> Reply-To: jimad@microsoft.UUCP (Jim ADCOCK) Organization: Microsoft Corp., Redmond WA Lines: 114 I disagree with Jonathan Shapiro's analysis of the issues with overloadable operator dot, and feel his arguments can be easily dismissed -- as always -- by seeing how well his arguments would also stack up against overloadable operator arrow -- which is already an accepted part of the language: [Maybe Jonathan needs to read a copy of the original proposal?] In article <1991May27.233113.14550@hal.com> shap@hal.com (Jonathan Shapiro) writes: >Why isn't operator '.' an operator? > >1. '.' has no well-defined type. The type of a.b is always typeof(b), >but there is no good definition for typeof(a). Following this same logic applied to overloadable operator arrow, one would come to the conclusion that overloadable operator arrow has no well-defined type, and thus cannot be included in the language. Yet, overloadable operator arrow *is* already in the language, and is widely used, and has a definite type. Thus there must be a flaw in Shapiro's argument. Perhaps he doesn't realize that operator dot is defined *by analogy* to operator arrow, and thus solves the "well-defined type" problem *the same way* ? Namely, given: class A { C* pc; .... C& operator.() { return *pc; } }; then: a.b; means: a.operator_dot().b; Note that: 1) a has a well-defined type, namely A 2) A::operator_dot() has a well-defined type, namely C& 3) so b has a well-defined type, namely that of C::b Again this is all by analogy to overloadable operator arrow. Overloadable operator dot simply allows "smart references" to do those things that are allowed of "smart pointers" today. >2. '.' is very heavily embedded into the C compilers, and C >compatibility remains a desirable goal for C++. > >What should happen to operator arrow in the unlikely event that >operator dot is introduced? The same thing that happened to operator arrow when overloadable operator arrow was introduced. Overloadable operator dot simply allows smart reference classes to be written, just as today one is allowed to write smart pointer classes. However, note that C doesn't even *allow references* so how could it possibly be that overloadable operator dot causes problems in regards to "C" whereas overloadable operator arrow does not ??? Smart references, and the features needed implement smart reference are purely a C++ problem. They impact "C" not a whit. [Again, I wonder if the problem is that Shapiro hasn't read the proposal?] >Operator arrow should retain the (*a).b semantics, and subsume the >functionality of BOTH operators. This argument is that some overloadable operators should have there meanings tied together. Whether this would have been a good idea or not, it's water long under the bridge. The rule in C++ is to allow programmers to overload "all" the operators necessary to do their job, and it is the programmer's responsibility to create a sensible and self consistent set of operators. If one allows overloadable operator dot, then there is nothing stopping programmers from writing a self- consistent set of operators. But, without overloadable operator dot, a programmer can't write a self-consistent set of operators. Thus, one gets these weird classes that use reference syntax in some places, and pointer syntax in others. Programmers can't reasonably help this -- since some miss-guided souls are doing their best to keep C++ programmers from having a full set of overloadable operators. Thus today, if a programmer wants to write a "smart" class that follows value semantics, that programmer is forced to use mixed syntax. For example, a reference counted "smart" array class: Array a; printf("%g\n", a[100]); // okay, overloaded operator[] // "value semantics" a.print(); // oops, can't do that no operator. // can't use "value semantics" a->print(); // okay, can overload operator-> // but now BAD mixture of // value and pointer semantics ---- The rule in C and C++ has always been to give the programmer the freedom and power to do their job as they see fit. This is a two edged sword. It gives the programmer the unparalleled power to hose themselves. It also gives them the ability to extend the language in powerful ways -- such as providing one or another garbage collection, or memory management schemes. Now, suddently some people want to restrict this freedom and responsibility. I don't understand this. Even if one believe that the freedom of C/C++ programmers should be certailed, trying to do so at this late a date is only leading to an inconsistent language. Please, let us keep C++ self-consistent, both in design and in philosophy. Let programmers overload "all" operators, and let them be responsible for doing so in a sensible way.