Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ihnp4!homxb!mhuxt!mhuxm!mhuxo!ulysses!allegra!alice!bs
From: bs@alice.UUCP
Newsgroups: comp.lang.c++
Subject: Re: Operator overloading considered harmful
Summary: not C++
Message-ID: <7607@alice.UUCP>
Date: 10 Jan 88 01:21:53 GMT
References: <240@vsi1.UUCP>
Organization: AT&T Bell Laboratories, Murray Hill NJ
Lines: 74



Steve Maurer from Vicom Systems Inc. San Jose, Cal. writes

 >     I have a bone to pick with operator overloading.    While
 > I must admit that it can be convienient at times, it suffers the
 > same problems that you get when dealing with someone who goes
 > crazy with #define's , or virtually anything written in Forth :
 > Essentially, every programmer becomes his own language designer,
 > and the whole thing gets totally unreadable.
 > 
 > Consider the following:
 > 
 >    foo(int i)
 >     {
 >     i #= i ^^ i @& i;
 >     }
 > 
 > what does it do??    You will never know unless you start digging
 > through miles of include/lib files.

It certainly does look obscure! I cannot even begin to imagine what it
might mean. I wonder which language it is supposed to be?

		     `Obfuscated C' maybe?

		>>>>>>> It is not C++ <<<<<<<

C++ allows you to define meanings for the existing operators for user
defiend types. It does NOT
	(1) enable you to define new operators or in other
		ways change the syntax of C++
	(2) enable you to change the meaning of operators
		applied to the built-in types.
These `restrictions' are enforced exactly to avoid nonsense such as
your example above.

Furthermore, it is strongly recommended to use operator overloading
ONLY where there is an established notation in some field of application
to adopt.

Standard examples are:

	Complex z1, z2; ... z1 += z2*complex(i,-j)+1.0;
		// += * and + overloaded

	Vector v1(100), v2(100); ... v1[i] = 7; ... v1 = v2;
		// subscripting and assignment overloaded

Most people would agree that given half way reasonable defininitions
of the types and operators involved this code is far more readable
than the standard C alternatives. If inline functions are used
judicially the run-time efficiency will also be good.

There are of course still truly horrible things that can be done with
the C++ operator overloading mechanism (such as defining + to be
an assignment operator or / to mean multiply), but then any mechanism
can be abused and I know of no useful language where horrors of similar
magnitude cannot be committed without the use of operator overloading.

In real use it may be a nastier problem that in C++ one cannot
introduce an exponentiation operator (**, ^^, or whatever) unless,
of course, the ANSI C committe suddenly reverses its stand on this
issue and provides an exponentiation operator for C. At least one
can overload the pow() function so that you automatically get the
appropriate algorithm for

	pow(10,7);		// pow(int,int) invoked
	pow(10.0, 7.0);		// pow(double,double) invoked
	pow(z1,2.3);		// pow(complex,double) invoked

provided, of course, that you have included the proper header file.

	- Bjarne Stroustrup (AT&T Bell Labs, Murray Hill)