Path: utzoo!utgpu!water!watmath!clyde!bellcore!faline!ulysses!allegra!mit-eddie!ll-xn!ames!oliveb!pyramid!voder!tolerant!vsi1!steve
From: steve@vsi1.UUCP
Newsgroups: comp.lang.c++
Subject: Re: Operator overloading considered harmful
Summary: Third round reply from original message, against Op overloading.
Message-ID: <265@vsi1.UUCP>
Date: 16 Jan 88 12:11:22 GMT
References: <240@vsi1.UUCP> <8180001@nucsrl.UUCP> <2607@calmasd.GE.COM>
Reply-To: steve@vsi1.UUCP (Steve Maurer)
Organization: Vicom Systems Inc. San Jose, Cal.
Lines: 111
Posted: Sat Jan 16 07:11:22 1988

>
[Edited for brevity]
>
> 	The philosophy of C++ was similar to that of C: rather
> than trying to force programmers into good programming practice by
> limiting them to only "safe" procedures (forcing extensions to the
> language or creative practices such as those employed in the various
> dialects of Pascal), you give them the power to hang themselves; or
> save themselves a lot of hassle.
> 
>	For example, the type "varstr" which means "variable-length
> string" was defined here, and is used as follows:
>
>	varstr a = "I am a";
>	varstr b = "I am b";
>	varstr c = a + b;
>	varstr d = "I am d";
>
>	d += " " + a;
>
>	cout << a << "\n" << b << "\n";
>	cout << c << "\n" << d << "\n";
>
>	This code is eminently readable, and what's more, we re-implemented
> varstr in two completely different ways, and yet the above code still
> worked.  Why?  Because the source code is at a higher level of abstraction
> than the implementation mechanism.
> 
> 	And on an on.  Of course, operator overloading can be misused
> much more easily than it can be used properly, but the same goes for
> the design of classes (it is easy to write a poorly designed class
> which works but ends up making code harder, not easier, to read.)  C++
> operator overloading is an indispensable and useful feature of the language,
> and like all powerful tools, not to be fooled with lightly.
>
>				-Mitsu Hadeishi
>				 Electronic Arts

    The one thing all defenders of any particular language will do when
confronted by criticism of a particular feature, is to say: "look how
useful it is in this situation; look what I can do with it".   All
languages have strong points, which clever examples can make good use
of (yes even Cobol).  However, this is not what should guide the
reviewer when determining the merits of any language.   Rather: How much
does this language or feature improve the ability to generate reliable,
maintainable, and flexible code; and at what cost in human and/or machine
efficiency is it bought?

    The thing that troubles me most about Operator overloading is that
definitions of basic operations, once static, are now contextual depending
upon the values of the particular programmer who wrote the header definition
code.  This is _by no means_ "bad" programming practice, but simply the
inherent method by which you must use Operator overloading.   And I believe,
after seeing similar do it yourself language design schemes (in Forth and
Structured Macro Assembly), that it can become the single greatest
obstruction to maintenence and portability of any program

    Plus '+' for instance, has always meant arithmetic addition.   Despite
arithmetic operators being "Overloaded" for different methods of machine
storage, in traditional languages the basic definition does not change.
Yet in the above example, we see '+' used for concatination.   Is
concatination now the same as addition?    If so, is '-' the same as
deletion?   Do '<', '>', and '==' stand for string comparison?   Does '/'
divide or deallocate the string somehow?    The answer is Yes, No, and
Maybe, depending upon the definitions in force under this brand of include
files.

    Perhaps strings aren't the best example.   After all, they are treated
uniformly by C convention, and there are few legal operations one might
perform on them.    Instead, lets take for example... 2 dimentional arrays.
What shall we define for them?    Does '+' mean "combine into a 4
dimentional array", "add each seperate element together, depositing
the results in a 2x array", or "give me the sum total of all these
numbers" ?    Does '*' indicate multiplication?   Or does it mean take
the dot product?   What does '/' do??   The answers are quite system
(or program) dependent.

    The above examples, I reiterate, are not "bad" programming practice
in C++.   They simply reflect the result of allowing each programmer
to select his own favorite notational convenience, and forcing him to
use a very limited set of operators which may not correspond well
(or at all) with the true functionality he is attempting to emulate.
Certainly standard operator notations may develop for commonly used
nomenclatures, but there is no guarantee that any such convention may
apply on any given machine, and there may very well be rival conventions.

    The alternative, of course, is to have every program carry around
its own operator definition environment.   Multiple standards will then
be the norm, and could become almost as much of a pain as switching
between System 5 and 4.3BSD.   This is what, in my opinion, kills
Forth, despite some extremely clever environments which some people
have created for it.   The language essentially becomes a haven for "loner"
programmers, whose programs don't execute until a large portion of
their specialized environment is loaded first.

    Now perhaps I have overemphasized the point about the inherent
dangers to Overloaded Operators too much, at least I certainly hope
so.  However, I am still not sure.  While Mr. Mitsu Hadeishi is correct 
in saying that C allows programmers the power to 'hang themselves, or
save a lot of hassle', at least in C, it is the programmer himself who
ends up being hanged.   In C++, the original programmer may design what
is to him an entirely natural and logical set of operators, never have
any trouble, and yet still leave a set of extremely difficult to
maintain code.    Because of this, I feel that it is a poor design
decision.

    I reserve the right to change my mind later, if and when a
perfect, 100% recognized, operational notation standard natually
develops for all common classes.   However, I'm not holding my breath.

					Steve Maurer