Operator overloading

Question

From language design point of view , What type of practice is supporting operator overloading?

What are the pros & cons (if any) ?

Answer 1

EDIT: it has been mentioned that std::complex is a much better example than std::string for "good use" of operator overloading, so I am including an example of that as well:

std::complex<double> c;
c = 10.0;
c += 2.0;
c = std::complex<double>(10.0, 1.0);
c = c + 10.0;

Aside from the constructor syntax, it looks and acts just like any other built in type.

---

The primary pro is that you can create new types which act like the built in types. A good example of this is std::string (see above for a better example) in c++. Which is implemented in the library and is not a basic type. Yet you can write things like:

std::string s = "hello"
s += " world";
if(s == "hello world") {
    //....
}

The downside is that it is easy to abuse. Poor choices in operator overloading can lead to accidentally inefficient or unclear code. Imagine if std::list had an operator[]. You may be tempted to write:

for(int i = 0; i < l.size(); ++i) {
    l[i] += 10;
}

that's an O(n^2) algorithm! Ouch. Fortunately, std::list does not have operator[] since it is assumed to be an efficient operation.

Answer 2

The initial driver is usually maths. Programmers want to add vectors and quaternions by writing a + b and multiply matrices by vectors with M * v.

It has much broader scope than that. For instance, smart pointers look syntactically like normal pointers, streams can look a bit like Unix pipes and various custom data structures can be used as if they were arrays (with strings as indexes, even!).

The general principle behind overloading is to allow library implementors to enhance the language in a seamless way. This is both a strength and a curse. It provides a very powerful way to make the language seem richer than it is out of the box, but it is also highly vulnerable to abuse (more so than many other C++ features).

Answer 3

Pros: you can end up with code which is simpler to read. Few people would argue that:

BigDecimal a = x.add(y).divide(z).plus(m.times(n));

is as easy to read as

BigDecimal a = ((x + y) / z) + (m * n); // Brackets added for clarity

Cons: it's harder to tell what's being called. I seem to remember that in C++, a statement of the form

a = b[i];

can end up performing 7 custom operations, although I can't remember what they all are. I may be slightly "off" on the example, but the principle is right - operator overloading and custom conversions can "hide" code.

Answer 4

You can do some interesting tricks with syntax (i.e. streams in C++) and you can make some code very concise. However, you can have the effect of making code very difficult to debug and understand. You sort of have to constantly be on your guard about the effects of various operators of different kinds of objects.

Answer 5

You might deem operator overloading as a kind of method/function overloading. It is part of polymorphism in object oriented language.

With overloading, each class of objects work like primitive types, which make classes more natural to use, just as easy as 1 + 2.

Say a complex number class, Complex. Complex(1,2i) + Complex(2,3i) yields Complex(3,5i). 5 + Complex(3, 2i) yields Complex(8, 2i). Complex(2, 4i) + -1.8 yields Complex(0.2, 4i).

It is much easier to use class this way. If there is no operator overloading, you have to use a bunch of class methods to denote 'add' and make the notation clumsy.

The operator overloading ought to be defined carefully; otherwise, comes confusion. For example, '+' operator is natural to adding numbers, time, date, or concatenation of array or text. Adding '+' operator to a class of Mouse or Car might not make any sense. Sometimes some overloading might not be seem natural to some people. For example, Array(1,2,3) + Array(3,4,5). Some might expect Array(4,6,8) but some expect Array(1,2,3,3,4,5).