Is Operator Overloading really necessary?

[Stupebrett]

I'm reading about operator overloading in my book at the moment, but I can't say I understand much of it. I haven't seen it in any programs (source codes), so is it really necessary to know? It just seems like my brain doesn't want to learn it.

[Disch]

It's not necessary for most things, no. All it does it give you a way to make your classes more intuitive to use. You can accomplish the same thing with member functions. The only one that might be necessary is overloading the assignment operator.


But really, if you understand member functions, you shouldn't have any problem understanding operator overloading. It's pretty much the exact same idea.

[filipe]

No it's not necessary at all. It's just a convenience, often abused. Some languages even disallow it.

[Stupebrett]

Ok, thanks for the answers!

[sohguanh]

I believe operator overloading make more sense to C++ classes that are maths-oriented. The reason because all we tend to associate + - += -= etc etc literals as doing some maths operation. For business-centric C++ classes, the use is less clear.

The only one operator overloading I like to use in almost all business-centric C++ classes is the ostream << operator. Very useful.

e.g
cout << my_C++_object << "\n"; //viola all the object data members are printed out for easier debugging purposes !

[Abramus]

I believe operator overloading make more sense to C++ classes that are maths-oriented.

It depends. Some time ago I created a fuzzy logic library. I overloaded all relational and logic operators for it, as this way the fuzzy logic expressions could look very similar to “normal” logic expressions. I think the library’s interface is better and clearer this way.

EDIT: But I guess fuzzy logic is kind of math-oriented.

The only one operator overloading I like to use in almost all business-centric C++ classes is the ostream << operator. Very useful.

Well, personally I think that a choice to overload “<<” and “>>” in the standard library is a mistake. I understand why it was done, but I still think that stdio has much better interface. The only downside is the lack of type checks.

[filipe]

+1 Abramus. Overloading the bit shift operators is such a bad idea that no language (that I know of) has copied it. stdio style formatting, on the other hand, is present in a lot of languages. It's just much more elegant and concise.

[zwA4jE8b]

I think it is really useful sometimes. Like when dealing with a rational number class (fraction A + fraction B) is much easier.

[helasraizam]

Indeed; and I'm making a matrix class, and when I define two matrices A and B, I want
A*B, A+B, A^3, B+=A, -A,
etc. to work!

[Disch]

Overloading the assignment operator actually will be necessary sometimes. Or at least necessary if you want proper encapsulation

EDIT:

As for iostream vs. stdio, they both have their faults.

stdio is not type safe, not dynamic, and arguably cryptic.

iostream is not threadsafe and arguably over verbose.


For fun way back in the day I made my own number->text formatting system that I thought addressed most of those points. It basically used the named parameter idiom to handle formatting options. So it ended up looking like this:

string foo = Convert(45067).Hex();

// or

foo = Convert(3.14).Sci().Width(5).Fill('0');

The other thing it did was act as a format style. So you could save an object and use it over again:

Convert fmt(0).Hex().Width(8).Fill('0');

foo = fmt.Set(10);
foo = fmt.Set(78);
//etc

// or

foo = Convert(1234,fmt);

[imi]

iostream is such a pain if you want to have localization support for a big application...

(Then again... printf - formats are an even worse pain if the reversed chinese symbol for dog pee happen to be % or something like that ^^)


And the "unnamed-variable-preventing" operator>> is clearly evil.