Path: utzoo!utgpu!water!watmath!clyde!rutgers!sri-spam!ames!ucbcad!ucbvax!decvax!decwrl!pyramid!voder!tolerant!vsi1!steve
From: steve@vsi1.UUCP (Steve Maurer)
Newsgroups: comp.lang.c++
Subject: Re: Operator overloading harmful (good criticism, bad example)
Message-ID: <250@vsi1.UUCP>
Date: 12 Jan 88 02:32:49 GMT
References: <240@vsi1.UUCP> <7607@alice.UUCP>
Reply-To: steve@vsi1.UUCP (Steve Maurer)
Organization: Vicom Systems Inc. San Jose, Cal.
Lines: 87

In article <7607@alice.UUCP> bs@alice.UUCP writes:
>
>
>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++ <<<<<<<

    I apologize for giving such a bad example, I had assumed that people
would recognize that '#=' and '^^' were being used for arbitrary members
of the restricted C++ operator set.    In fact, if C++ placed the
restriction that all overloaded operaters WERE NOT part of the standard
set, I would have little objection to it.    As so eloquently, and
verbosely pointed out on the net, such a construct is really nothing but
syntactic sugaring of the function call interface, as programmers can
easily recognize them for what they are.   ( Although precedence and
associtivity handling would be a bitch, I suppose you could get around
this by the addition of description keywords to apply to 'operator' - e.g.
left associativity for a user defined operator would be (in part):
friend X lassc operator$(X,X) )

    However, as currently implemented, I am not so sure.    Consider
my 'corrected' example:


    i = d[ a + b * c ];


    What does it do?   As the maintainer, I have to not only know the
classes of all the objects involved, but also the potentially baroque
series of code and rules about overloading, member/nonmember
functionality, and conversion operators.

    Although it is true that operators cannot be redefined for basic
types, I believe that this will not be helpful towards disambiguating
the code.  Because, in my experience, most C programmers (including
myself) who are in the middle of a large program, often forget or
misremember the class of a variable they are working with, and use
operators existing in the code to help disabiguate the situation.
C++ removes this cozy relationship, and will most probably cause major
heartburn.

    In addition, although I do find Mr Stroustrup's book quite well
written, the syntax and nonintuitive rules forced upon the language
designers to implement operator overloading, will most likely make the
correct programming of such operators quite difficult.   And the one
thing that I do not want to do is to find out that my C++ program, which
worked on machine A (with header file xyz included), does not work on
machine B (with header file zyx).

    So what to do?   (I intend this to be constructive criticism after
all).    Considering the small set of operator/class types which the
authors of C++ intended to simulate via this construct, is it not possible
to simply introduce (i.e. publish) a Standard set of them?    The stdio
library in C is a direct analogue, since neither case are the functions
directly implied by the language, yet both (I believe) are imperitive to
maintaining portability and sanity.

    This would also allow the authors to say in so many words:

"Operator Overloading is both complex and dangerous, proceed at your own risk"

    with some sense of believability.


						Steve Maurer