steve@vsi1.UUCP (Steve Maurer) (01/12/88)
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
faustus@ic.Berkeley.EDU (Wayne A. Christopher) (01/13/88)
You just have to make sure that whenever you use operator overloading, the operators do The Right Thing. Don't use `+' unless the operation you're doing is some form of addition (matrix, complex, etc), and is the obvious way to add things of the arguments' types. It's a matter of common sense... Wayne
darin@apple.UUCP (Darin Adler) (01/14/88)
In article <250@vsi1.UUCP> steve@vsi1.UUCP (Steve Maurer) writes: > However, as currently implemented, I am not so sure. Consider > my 'corrected' example: > > i = d[ a + b * c ]; > > What does it do? The great advantage of operator overloading is that it allows the programmer to *extend* the definition of the basic operators so that they work properly with user-defined classes. If I define a class to handle english measurement length first, second; (for example), I would much rather write length sum = first + second; than length sum = add(first, second); In both examples, however, C++ allows me to define the operation of adding (either the operator "+" or the function "add") so that it will work properly for each of my defined classes. Even better, C++ assures me that if I use the operator or function in such a way that it is ambiguous or unimplemented (for example, trying to add an int to a variable "length" class), the C++ pre- processor (or compiler :-) will warn of such an ambiguous use. Clearly, what you object to is not "operator overloading", but overloading in general. When using overloading, there is a tradeoff. By writing a group of functions, and referring to them by one name, we imply that they all do the equivalent thing with their variously typed operands. I believe that when overloading, one must be very careful not to define different meanings for the same operator or function in different contexts. Because of this, I strongly object to the use of the "<<" and ">>" operators by the streams package in standard C++. Although I find it convenient, I think it sets a poor precedent. -- Darin Adler, Apple Computer AppleLink:Adler4 UUCP: {sun,voder,nsc,mtxinu,dual}!apple!darin CSNET: darin@Apple.com
jima@hplsla.HP.COM (jim adcock ) (01/14/88)
> i = d[ a + b * c ]; > > What does it do? *** SIGH *** Hopefully, what it does is assign i the value of the (a plus (b times c))'eth element of d. If not, it was probably written by a brain dead programmer. Would you RATHER try to maintain a program consisting of thousands of lines of the following type of code ??? assign(i,index(d,sum(a,product(b,c)))); I've certainly seen PLENTY of code of the above variety, simply because MOST languages have NO OTHER WAY to express math formulas on anything more complicated than a floating point number. WHICH code do YOU believe is more likely to have the BUG in it in the FIRST place, the line of code using standard math symbols, or the line of code consisting soley of "prose" descriptions? WHICH code do YOU believe would be faster and easier to write? C++ allows standard mathematical intuition with regards to mathematical formulas to be applied to things more complicated than floating point numbers -- complex numbers, vectors, matrices, sparse arrays, etc, etc. -- I believe the goal of C++ is to allow GOOD programmers to write GOOD code -- In my experience, when you take inexperienced programmers, and put them onto a good language, MOST tend to rise to the occasion, and write code at the quality level that the language allows. I believe most programmers WANT to do a good job. It's the butting you head against a language that doesn't ALLOW good programming that leads to the bad code, because then programmers give up in frustration, and crank out any old style code. In any case, it will be good code, written by good programmers, that will tend to survive and propagate over the years, serving as example for future C++ programmers. Certainly, I share your fears that until a volume of C++ programs develop, such that the C++ community starts to form a natural consenses as to what represents "good" C++ programming style, until then there ARE going to be some pretty weird examples of people going off the deap end, using C++ features in some pretty bizarre ways. But I have no doubt that the C++ community will recognize these efforts for the garbage that they truly are. For me, a bigger concern than the people who might overload "+" to mean "So Fred, wanna havva pizza for lunch" are the people who are blindly trying to force C++ programming into a Smalltalk-like mold. I am far from convinced that the Smalltalk-style of object oriented programming truly represents the direction that the C++ community should head towards. [[I won't even MENTION what I think about people who hack cfront !!!]] "Fool-proof tools are only fit for use by fools"