Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!pasteur!ucbvax!sdcsvax!sdcc6!calmasd!wlp
From: wlp@calmasd.GE.COM (Walter Peterson)
Newsgroups: comp.lang.c++
Subject: Re: Operator overloading considered harmful
Summary: Operator overloading
Message-ID: <2607@calmasd.GE.COM>
Date: 12 Jan 88 17:03:04 GMT
References: <240@vsi1.UUCP> <8180001@nucsrl.UUCP>
Organization: G.E.- Calma R&D, San Diego, CA
Lines: 55


One fact that most people seem to forget in regards to operator overloading
is that we have used it for years in virtually every high order language.
FORTRAN, C, Pascal, etc. all effectively use operator overloading, even if
they do not allow the programmer to extend the overloading that already exists
in the language definition.  Consider the following code segments:


FORTRAN
    .
    .
    .
    INUM = INUM + 5 * ICOUNT
    AREAL = AREAL * BREAL
    AREAL = AREAL + CREAL
    IVAL = IVAL / 2
    .
    .
    .


Pascal
     .
     .
     Num, Val : Integer;
     Percent, Score, Max, Bonus  : Real;
     .
     .
     Num = Num * Val + 1;
     Percent = (Score / Max) + Bonus;
     Val = Val * Num / 2;
     .
     .

In these examples there are overloaded operators.  In every high level language
that I can think of the assignment, addition, subtraction, multiplication and
division operators are overloaded ( as are the logical operators,
exponentiation and most if not all other operators ). Additionally some
languages further overload the addition operator to allow concatenation of 
strings.

The point is that there is nothing new to programmers about the use of operator
overloading; we have all been using it for years, even if we didn't know it.
Yes, we have all made the mistake of trying to perform invalid mixed-mode
arithmetic, but just imagine how many more mistakes we would make if we had to
learn to use a different set of operators for each and every type in C !

The advantages of being able to overload operators for user defined types far
outweigh the potential disadvantages ( most of which are caused by sloppy 
programming ).
-- 
Walt Peterson   GE-Calma San Diego R&D
"The opinions expressed here are my own and do not necessarily reflect those
GE, GE-Calma nor anyone else.
...{ucbvax|decvax}!sdcsvax!calmasd!wlp        wlp@calmasd.GE.COM