rfg@NCD.COM (Ron Guilmette) (09/21/90)
In article <57570@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes: > >-- Please join me in lobbying the ANSI C++ committee to correct this oversight >in the language definition. Overloading operator.() makes equal sense for >reference classes as overloading operator->() for pointer classes... Finally, Jim and I have found something to agree on. :-) I'd say that Jim is correct is saying that treating either `.' or `->' as if they were OPERATORS (kinda like other operators) makes equal sense, i.e. *NONE*! Allowing overloading for either of these makes about as much sense as allowing overloading for `{' or `}'. Look folks, just because a particular C++ token contains some non- alphanumeric characters does not make it an operator! OK. Back to basics. What is `->'? Well, it is (syntactic sugar) shorthand notation for `*.' (i.e. dereference and select). So whenever I write: a->b (in C anyway) that's always equivalent to: (*a).b The meaning is clear and unambiguous. Apply the prefix unary dereference operator to the thing on the left, and then select out a member from the result. Now I've got no problem with (or objection to) allowing overloading for the unary prefix dereference operator BECAUSE THAT *IS* AN OPERATOR IN EVERY SENSE OF THE WORD. I do object (most violently) however to any attempts to call the selector `.' a `binary operator' (or to treat it as though it were one). Obviously, it isn't. For all of the binary operators that *I* know of, either the left or the right operands may be arbitrarily complex *expressions* (so long as these expressions evaluate to some type of value which is appropriate for the given category of operator). This is clearly *not* true in the case of the selector `.'. For the selector, the thing on the right *must* be a (qualified or unqualified) identifier which designates a some member belonging to the type of the thing on the left. The thing on the right *cannot* be an arbitrarily complex expression. It must be an identifier. Furthermore, the identifier *cannot* refer to any complete *object*. Rather, it must refer to a *member*. So the selector is *not* an operator. Period. Allowing overloading for it would make about as much sense as allowing overloading for `{' or `}' or `::' or `"'. Likewise, since `->' is just a shorthand notation for a combination of an operator (i.e. unary prefix dereference) and the selector, allowing overloading for `->' make as little sense as allowing it for the selector all by itself, i.e. none whatsoever. I can't understand why Bjarne and Jim and others have so much difficulty seeing the fundamental irrationality of allowing operator overloading to be done to things which are clearly not operators. If they really think that this is such a swell idea, then I challenge them to tell me (and everyone) why they are not suggesting allowing `operator{' to be overloaded. If there are any rules for what should be called an operator and what should not, and what should be overloadable and what should not, I'd like to see them! If these rules are at all consistant, if they make any sense whatsoever, and if they still would seem to permit -> to be overloaded, I'll eat my hat. -- // Ron Guilmette - C++ Entomologist // Internet: rfg@ncd.com uucp: ...uunet!lupine!rfg // Motto: If it sticks, force it. If it breaks, it needed replacing anyway.