Path: utzoo!utgpu!water!watmath!clyde!rutgers!rochester!udel!gatech!mcnc!decvax!decwrl!pyramid!voder!apple!darin
From: darin@apple.UUCP (Darin Adler)
Newsgroups: comp.lang.c++
Subject: Re: Operator overloading harmful
Message-ID: <7177@apple.UUCP>
Date: 13 Jan 88 17:52:12 GMT
References: <240@vsi1.UUCP> <7607@alice.UUCP> <250@vsi1.UUCP>
Reply-To: darin@apple.UUCP (Darin Adler)
Organization: Apple
Lines: 45

In article <250@vsi1.UUCP> steve@vsi1.UUCP (Steve Maurer) writes:
>     However, as currently implemented, I am not so sure.    Consider
> my 'corrected' example:
> 
>     i = d[ a + b * c ];
> 
>     What does it do?

The great advantage of operator overloading is that it allows the programmer
to *extend* the definition of the basic operators so that they work properly
with user-defined classes. If I define a class to handle english measurement

	length first, second;

(for example), I would much rather write


	length sum = first + second;

than

	length sum = add(first, second);

In both examples, however, C++ allows me to define the operation of adding
(either the operator "+" or the function "add") so that it will work properly
for each of my defined classes. Even better, C++ assures me that if I use the
operator or function in such a way that it is ambiguous or unimplemented (for
example, trying to add an int to a variable "length" class), the C++ pre-
processor (or compiler :-) will warn of such an ambiguous use.

Clearly, what you object to is not "operator overloading", but overloading in
general.

When using overloading, there is a tradeoff. By writing a group of functions,
and referring to them by one name, we imply that they all do the equivalent
thing with their variously typed operands. I believe that when overloading,
one must be very careful not to define different meanings for the same
operator or function in different contexts.

Because of this, I strongly object to the use of the "<<" and ">>" operators
by the streams package in standard C++. Although I find it convenient, I think
it sets a poor precedent.
-- 
Darin Adler, Apple Computer                          AppleLink:Adler4
UUCP: {sun,voder,nsc,mtxinu,dual}!apple!darin  CSNET: darin@Apple.com