[question] Operator overload

[Đăng]

my teacher asked me "Why c++/c## support operator overloading and java don't?"
I have an answer for Java.
anything I read, just said about how to write, define or something else. No answer for "why"
someone can give me a document which I need or the answer.
thanks for reading and sorry about my poor english

[Rashakil Fol]

You should look for interviews with and documents written by the designers of these languages.

[NathanOliver]

Well if you have why Java doesnt then that answers the question. Think of it as "Why does Java not support operator overloading?".

[rubberman]

There are a number of good discussions on the internet about this - try a google search on the terms "java operator overloading". The short answer is that java does copy-by-reference vs. C++ (and I assume C#) using copy-by-value. Here is one link for you that tries to explain it: http://stackoverflow.com/questions/77718/why-doesnt-java-offer-operator-overloading

[Rajeev Kumar_1]

This is more the java question than c++.

java is a pure object orented language so all the bad effects of c++ is remove and operator overloading is one of them.

[NathanOliver]

@ Rajeev Kumar_1: how is operator overloading bad?

[jwenting]

operator overloading isn't bad in theory, but it has such massive opportunities for abuse, and in the wild is hardly ever used except incorrectly, that the designers of Java decided to do without in order to prevent an entire class of problems relating to the concept.
From operators with side effects, operators doing utterly illogical things (think Strawberry operator+(Apple a, Orange b)), the list goes on and on.

[NathanOliver]

That doesn’t make operator overloading bad. Even Java has certain types that have operator overloads because it is so natural for that type. Take string for example. The + operator works with it even though it shouldn’t since there is no operator overloading in the language. If anyone ever gave me code with Strawberry operator+(Apple a, Orange b) in it I wouldn’t blame the language, I would fire the programmer.

[jwenting]

Java being programmed to make bad code harder to write (it's still possible, the moment you make things more fool proof nature creates a batter fool after all) they decided to not include certain capabilities that are extremely easy to abuse and very hard to use correctly, things like operator overloading and direct memory management.
That's all there is to it.

[NathanOliver]

Java being programmed to make bad code harder to write

I don’t think there is a language on earth that makes bad code harder to write. I do understand why the designer decided to not let it in It just kills me that people think it is the language feature that is dangerous when in actuality it is inexperienced programmers that are dangerous.

[jwenting]

operator overloading is not just dangerous in the hands of inexperienced programmers.
In fact in my experience it's most dangerous in the hands of experienced programmers who're overconfident and too clever for their own good, and as a result end up butchering it (and other language features) with "smart" things.

[Rashakil Fol]

Operator overloading isn't bad. The worst case scenario is that you have a badly named function. It is completely sensible and necessary for many things in C++ that are good, like smart pointer types, generic programing over iterators, and collections. Not to mention assignment.

That you even stop to gasp about operator overloading as if it had any real negative impact on C++ development shows what shallow understanding you have.

[iamthwee]

To avoid the dangers of operator overloading as outlined,java omits them instead opting for a less verbose and easy to understand syntax.

Example in c++

cout << Strawberry c + (Apple a, Orange b);

Would be in java

System.up.down.in.out.left.right.turn.around.touch.the.floor.println( afruit.frombowl(strawberry).plus.((afruit.frombowl(apple),(afruit.frombowl(orange))

I think we can all agree the above syntax is less verbose demonstrating why java has the upper hand and has opted for a no 'operator overloading' policy. This ensures code is safer even when the programmer doesn't know what they are doing.

[melissad]

In programming, operator overloading—less commonly known as operator ad hoc polymorphism—is a specific case of polymorphism, where different operators have different implementations depending on their arguments. Operator overloading is generally defined by the language, the programmer, or both.

[cheryllocascio]

Java does not support many features which can be used in C++. Yes one of them is operator overloading. One of the important features of Java is that it is simple. If the operator overloading is used it would surely make the design more complex. It might also slow the JVM, as it might need to perform extra work to find the actual meaning of teh operators used. When a language supports operator overloading you can see the increase in the programming errors too. Supporting the operator overloading could be more difficult if we look from the JVM viewpoint. The same can be achieved by the technique of method overloading which can be achieved in the clean and the intuitive way. Exclusion of operator overloading has preserved the language easier to handle and process, which have made it easier to develop the tools, that process the language or re-factoring the tool.

[mike_2000_17]

It baffles me that all this discussion can go on about the pros and cons of operator overloading and trying to explain why Java's designers decided to exclude operator overloading altogether out of some sort of principle or good coding practices concern against them as a whole. The reality is much more pragmatic.

The main feature that enables operator overloading in C++ in a practical way is the set of ADL rules (Argument Dependent Lookup rules, or Koenig Lookup). If you call a free function (operator overload or not), the compiler looks at the types of the arguments and all the available overload candidates, and follows a number of rules to determine the most suitable candidate, and if there is no ambiguity, resolves the call to that candidate.

Java has, obviously, similar rules for resolving overloaded methods, but not free functions, because free functions don't exist! You could say that free functions are emulated in Java using static methods, but you cannot create overloads of static methods of an existing class, i.e., all the overloads must be defined within that class. This restriction is a blessing for Java's compilers / JVM / JIT compilers because it greatly simplifies the problem of overload resolution by providing a central location for overload candidates.

Consider the problem of heterogeneous operator overloads. Something like this:

MixedJuice operator+(OrangeJuice o, AppleJuice a);

There is no generally good answer to the problem of where such an operator should reside: In the OrangeJuice class? In the AppleJuice class? Or in the MixedJuice class?

Having it in either of the operands' class methods creates semantic and technical problems. The semantic problem is that of "why should the OrangeJuice class be concerned about the addition of another juice like AppleJuice?", i.e., it makes no sense that such a method should belong to any one of the classes (i.e., the semantics are wrong). The technical problem is mainly that it introduces an unecessary dependency between the two operand classes, and it also suffers from the infamous scalability problems of a naive implementation of double-dispatch.

Having the operator as part of the MixedJuice class has pretty much the same problems as with placing it in either operand classes. But on top of that, the expected return type now becomes a determining factor in the overload resolution, which is a big problem from a language-technical perspective. When the language includes various implicit conversion rules, you get into a messy situation of having to consider those potential conversions, and the benefits of having overloading rules that a local to a single class' methods now go away. Even C++, with it's more complex ADL rules doesn't support overloading on return types for that very reason.

For all these reasons, the general recommendation and good practices in C++ when it comes to operator overloading is to use free functions to implement them. Good practices in C++ dictate to try, in order: (1) non-friend non-member functions, (2) friend functions, and (3) member functions for operators that require it. Furthermore, good and scalable implementations of heterogeneous operator overloads (e.g., when implementing a DSEL) require the use of additional static dispatching methods under the hood of those operator overloads (such as SFINAE and tag-dispatching) to ease the burden of the compiler when resolving complex multiple-dispatch schemes.

When you lay things out the way I just did, you realize that considering the restrictions that Java is starting from (no free functions, weak ADL) and what is required to implement robust and scalable operator overloading schemes (or DSELs), which are some of the mechanisms for which C++ is famous for (or infamous for, depending on your perspective). Then you see that operator overloading is better left out of the Java language, because, at best, it could only provide a terrible, unscalable and unusable version of it, like C# did. Overall, I give kudos to the designers of Java for not including this seductive feature which would have done more harm than good to the Java language.

C++ can have operator overloading because it has the power to support it well, for those who know how to use it well (which is definitely a rare talent, no doubt about that!). And I agree that operator overloading can be and is very often abused for ungodly purposes, but it is a central feature for writing DSELs (Domain Specific Embedded Languages) which is a very powerful and useful part of C++. I say that either you are implementing a DSEL and can use operator overloading in that context (a DSEL means that you redefine the semantics of operators in a globally coherent way, within your DSEL), or you should stay away from them altogether (except for basic "member" operators like assignments and conversions).