jbuck@janus.Berkeley.EDU (Joe Buck) (04/12/91)
There seems to be some confusion among some people about just what
the "overloaded operator dot" proposal is all about. The proposal
is intended (as Jim Adcock has argued very effectively) to make C++
a more symmetrical language. The implementation and restrictions
are strictly analogous to those with operator -> described in section
13.4.6 of the ARM. For every "identity" that adding operator. would
violate, an equivalent identity is violated by the presence of overloaded
operator -> .
For those who say "dot is not an operator (Ron G.)", neither, in the sense you
mean, is ->. Ron, I seriously suggest that you read section 13.4.6 again.
To be formal about it, to obtain the new section, first replace the
title of section 13.4.6 with "Class Member Access Using Pointer Notation"
and leave all the text the same. Now make a duplicate of the entire
section with your text editor, forming section 13.4.6b. Title this
section "Class Member Access Using Reference Notation". Then change,
in the new section, "->" to "." and "pointer" to "reference". Then,
just as operator->() must return something that can be used as a pointer,
operator.() must return something that can be used as a reference (either
because it is a reference, or because operator.() is defined for it).
If you think operator.() is kludgy, you have some justification, but you
must then admit that operator->() is equally kludgy. Either both or
neither should be in the language. In many cases, a reference notation
gives easier-to-understand, easier-to-write code than a pointer notation
does. Given this, there isn't a good reason to force the user to write
"smart pointers" when "smart references" are more natural.
--
Joe Buck
jbuck@janus.berkeley.edu {uunet,ucbvax}!janus.berkeley.edu!jbuck rfg@NCD.COM (Ron Guilmette) (04/22/91)
In article <41694@ucbvax.BERKELEY.EDU> jbuck@janus.Berkeley.EDU (Joe Buck) writes: >There seems to be some confusion among some people about just what >the "overloaded operator dot" proposal is all about. The proposal >is intended (as Jim Adcock has argued very effectively) to make C++ >a more symmetrical language. I agree that the language would be more symmetrical if it allowed either *both* of -> and . to be overloaded or *neither*. >For those who say "dot is not an operator (Ron G.)", neither, in the sense you >mean, is ->. Ron, I seriously suggest that you read section 13.4.6 again. I read it. Now what? The fact that Bjarne and Jim Adcock and you all decided (incorrectly) to call -> an operator does not have any particular influence upon me. I'll continue to call a spade a spade no matter how many others tell me it isn't. >If you think operator.() is kludgy, you have some justification... Gosh! We are in agreement after all! >...but you >must then admit that operator->() is equally kludgy. Either both or >neither should be in the language. Agreed. I vote for neither. -- // Ron ("Loose Cannon") Guilmette // Internet: rfg@ncd.com uucp: ...uunet!lupine!rfg // New motto: If it ain't broke, try using a bigger hammer.
gintera@cpsc.ucalgary.ca (Andrew Ginter) (06/11/91)
In article <1991May27.233113.14550@hal.com> shap@hal.com (Jonathan Shapiro) writes: >As one of the people who helped cause operator-> to come into >existance, I want to draw out some problems of understanding in the >operator-> exchange that I have seen. ... >The problem with answer (1) lies in the undefined lifespan of the >temporary object. One of the important uses of operator arrow and >operator * is in supporting pseudo-garbage-collection and locking >primatives. Look at what happens in the code: > > c = a->b; > f(c); > >In proposal 1, the compiler is free to generate > > tmp = (*a) > c = tmp.b; > destroy(tmp) > f(c); > >This would break an operator * based locking scheme. Look at what happens with existing support for the "->" operator: c = (a()) -> b; f (c); Compilers are currently free to generate: tmp = a(); c = tmp -> b; destroy(tmp); f(c); This breaks an operator-> based locking scheme. As one of the people who helped cause operator-> to come into existance, can you tell us if this problem was discussed at all? How should it be dealt with? Andrew Ginter, 403-220-6320, gintera@cpsc.ucalgary.ca
jimad@microsoft.UUCP (Jim ADCOCK) (06/15/91)
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.