Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!oliveb!ames!sgi!mtoy
From: mtoy@xman.SGI.COM (Michael Toy -- The S.G.I. XMAN)
Newsgroups: comp.lang.c++
Subject: Re: Operator overloading considered harmful (again, sorry!)
Message-ID: <9893@sgi.SGI.COM>
Date: 22 Jan 88 21:50:43 GMT
References: <240@vsi1.UUCP> <8180001@nucsrl.UUCP> <2607@calmasd.GE.COM> <276@vsi1.UUCP>
Sender: daemon@sgi.SGI.COM
Organization: Silicon Graphics Inc, Mountain View, CA
Lines: 43

This looks like an argument that is going nowhere, so I thought I'd go along
for the ride.

It appears to me that Steve Maurer's concern about operator overloading
is that things which used to be set in concrete, that you could rely
upon, like "+" meaning add, are now up in the air.  And I beleive I
recall him being concerned about the meaning of a program changing
depending on which set of include files is used.  Thus a line like "a
+= 3", which used to require very little mental energy to parse, now
requires you be intimate with the implementation of the type of "a" to
know exactly what that means.  These concerns come from a desire to
have people write code which is "maintainable" by people other than the
original author.

So I have these observations:

1) The definition of "+" for two integers will never change.  If I see
"int a,b; a = b + a;" I'll always know what that means regardless of
what include files I have, operator overloading is only valid for new
types.  Thus C++ code written using exisiting C features is no less
maintainable than it would be if it were used in a pure C environment.

2) Even without operator overloading, it is necessary to be fairly familiar
with the functions and variables assocaited with a class in order to
understand code which uses instances for that class.  Thus having to be
intimate with the type of "a" to understand "a += 3" is no worse than
having to know about "a" to understand "a::open"

3) If a class is "clean" (see The Book, Preface: Thinking about Programming
in C++) then it should be clear to one who understands the abstraction that
the class represents, what a particular overloaded operator means.  And even if
it isn't exactly clear, (like to "*" mean dot product or some other thing)
a quick glance can fix that once and for all.

4) Exisiting C, through the use of #define already has keyword overloading
and you can never really know what a C program does unless you read all
it's include files.  And yet, with a couple of infamous exceptions, people
have not gone crazy with this feature but have some managed to restrain
themselves and write, maintainable code even though the were given a very long
rope with which to hang themselves.
--
Michael Toy, secret identity: the XMAN at Silicon Graphics
						{ames,decwrl,sun}!sgi!mtoy