Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ihnp4!homxb!mtuxo!mtune!codas!ateng!chip
From: chip@ateng.UUCP (Chip Salzenberg)
Newsgroups: comp.lang.c++
Subject: Re: Operator overloading considered harmful
Message-ID: <159@ateng.UUCP>
Date: 22 Jan 88 15:47:34 GMT
References: <240@vsi1.UUCP> <8180001@nucsrl.UUCP> <2607@calmasd.GE.COM> <265@vsi1.UUCP>
Reply-To: chip@ateng.UUCP (Chip Salzenberg)
Organization: A T Engineering, Tampa, FL
Lines: 55

In article <265@vsi1.UUCP> steve@vsi1.UUCP (Steve Maurer) writes:
>
>    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 no big deal.  C already has this "problem" with program-specific
macros and libraries.  Let's not fall into the trap of considering a
facility to be good only if it's universally available in a standard form.

>[Operator overloading] can become the single greatest
>obstruction to maintenence and portability of any program...

Just because it _can_ become a problem does not mean that it _will_.
Unless the programmer allows it to become a problem, that is.

>[re: using + to mean string concatenation]
>Is concatenation now the same as addition?

Of course not.  Neither is writing to a CRT the same as writing to a file.
Yet I have heard no one complain that they don't like the UNIX write()
call just because they can't tell what it does by looking at it.

>    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.

With the possible exception of operator= (assignment), no programmer is
ever _forced_ to use operators.  If a programmer uses an operator to
represent something quite different conceptually from the normal meaning of
that operator, that programmer has written _bad code_.  So should we limit
all programmers just because some make mistakes?  Of course not.

>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.

Who cares?  This isn't Smalltalk, where every class fits into one big
hierarchy.  C++ has lots of little hierarchies.  Differing conventions
don't break programs.

>    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.

Anything 100% recognized is 100% fossilized, and must by definition be
acceptable to all its users. (Can you say "ANSI C"?) If C++ were in that
state, I'd move on to something less "standard" and more useful.
-- 
Chip Salzenberg                 UUCP: "{codas,uunet}!ateng!chip"
A T Engineering                 My employer's opinions are a trade secret.
       "Anything that works is better than anything that doesn't."