Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!hellgate.utah.edu!uplherc!wicat!meph!gsarff From: gsarff@meph.UUCP (Gary Sarff) Newsgroups: comp.lang.c Subject: Re: Personal dialects and C++ overloading Message-ID: <00017@meph.UUCP> Date: 17 Feb 90 00:28:03 GMT References: <5940014@hpcupt1.HP.COM> <33889@ucbvax.BERKELEY.EDU> <1922@gmdzi.UUCP> < <1990Jan29.210357.366@eng.umd.edu> <90029.194640JI8@PSUVM.BITNET> <4152@helios.TAMU.EDU> <926.18:17:58@stealth.acf.nyu.edu> <4301@daff Organization: WICAT Systems Inc., Orem Utah Lines: 61 In article <4301@daffy.cs.wisc.edu>, schaut@cat9.cs.wisc.edu (Rick Schaut) writes: >Regarding overloading of operators: > >In article <926.18:17:58@stealth.acf.nyu.edu> brnstnd@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.