Personal dialects and C++ overloading
Gary Sarff
gsarff at meph.UUCP
Sat Feb 17 11:28:03 AEST 1990
In article <4301 at daffy.cs.wisc.edu>, schaut at cat9.cs.wisc.edu (Rick Schaut) writes:
>Regarding overloading of operators:
>
>In article <926.18:17:58 at stealth.acf.nyu.edu> brnstnd at stealth.acf.nyu.edu (Dan Bernstein) writes:
>| This Ada (and, by imitation, Fortran 90 and C++) misfeature makes
>| program maintenance a nightmare. The problem isn't just that it's a pain
>| to locate the routine that adds a GLORP to a FOOBIEBLETCH. The problem
>| is that you won't even notice the nonstandard usage until it's too late.
>
>Any compiler that would allow you to apply the "+" operator to a "GLORP"
>and a "FOOBIEBLETCH" doesn't conform to the notion of overloading.
Why not, if that is what I want, and that is the way I declared the operator
to work? I want + to add 1 operand of type GLORP to one of type
FOOBIEBLETCH. They don't necessarily have to be the same type of objects to
overload.
>Overloading does _not_ come at the expense of strong type checking. It
>_does_, however, allow the programmer to apply the abstract notion of
>"addition" to objects for which such an operation makes sense (e.g. sets).
Makes sense to whom? You? Me? A foreign programmer who doesn't speak your
native english?
>
>Of course overloading the "+" operator to mean set difference when the two
>operands are sets doesn't make much sense in the semantics of any language.
Again, make sense to whom?
>Does passing an array of characters in a parameter that is supposed to be
>a pointer to a FILE object make much sense?
>
>| Overloading saves typing time. It has no other advantages. (Is it an
>| advantage to be able to code without thinking and make undetectable
>| syntax errors?)
>
>Overloading saves having to think about the mechanics of calling the
>correct procedure whilst allowing the programmer to think more about the
>semantics of the program. It's not a case of being able to code without
>thinking. Rather, it's a case of being able to code while thinking about
>that which is important.
>
I think the original poster's point, and the reason I have always distrusted
overloading, (as in Ada when the whole point is supposed to be reliability
and ease of maintainability) is that when you have overloading, you must have
all source code, headers, module def's, whatever available to you (the way
the compiler does) or the meaning of any statement you see that has operators
in it cannot be deduced by you. This is ease of maintainability??
Even if you can determine the types of a,b, and c, and you see
a = b + c;
do you _REALLY_ know the semantics of this, what if I overloaded + to do
something really strange, like b + c = 1 if b and c are mutually prime?
Doesn't make sense to you, (or me either), but that isn't the point. The
compiler won't stop me from doing this, the language definition allows it.
The only restraint we have that something like this won't happen is the
restraint of the originating programmer. Features like that in any language
are at least a bit scary to contemplate.
More information about the Comp.lang.c
mailing list