Click here to Skip to main content
15,843,322 members
Please Sign up or sign in to vote.
4.71/5 (6 votes)
See more:
Why do we overload operators? Can an overloaded operator change its original meaning in so far that the * operator can be used for +?

Thanks in advance!
Posted
Updated 18-Jan-11 11:16am
v2
Comments
Manfred Rudolf Bihy 18-Jan-11 16:39pm    
I voted 5 for your question as it is a really interesting one that really deserves some consideration. Not everything that can be done should also be done, but if we're not prepared to ask the right questions we might fall victim to all kind of fallacies!
Espen Harlinn 19-Jan-11 9:33am    
5+ Resulted in a rather nice and intersting "discussion"

Yes indeed - you can make most operators do anything you want, but please don't make a * into a + - it's a bad idea, unless you really intend to confuse you coworkers.

As a rule of thumb I think operator overloading shoul be used to provide logic that's semantically compatible whith the operator in question.

Now, here is a library that does not adhere to that "rule of thumb" Boost Spirit[^] is an excellent example of putting operator overloading to good use - redefining the operators to enable definition of grammars in c++, using a notation that closely adheres to EBNF. In my opinion this makes sense since grammars are usually specified in EBNF.

Regards
Espen Harlinn
 
Share this answer
 
v3
Comments
Sergey Alexandrovich Kryukov 18-Jan-11 16:10pm    
Same thing - a 5, but the use of brackets should be noted.
Manfred Rudolf Bihy 18-Jan-11 16:14pm    
Sematically compatible, good point! 5+
See my answer I think we agree.
fjdiewornncalwe 18-Jan-11 16:47pm    
+5... I can't help but think that "don't make a * into a +" deserves to have "because someone maintaining the code later will say '*%@#$%@' about what you did."
Espen Harlinn 18-Jan-11 16:54pm    
Thanks Marcus
Emilio Garavaglia 19-Jan-11 2:48am    
well ... boost spirit make a use of operators that has nothing to deal with the operator original meaning (and the same can be said about iostreams: << is "bit shift" after all!)

The reason why this is a "good use" while me -writing a non conventional use of an opertor- i'm doing "bad use" looks partigian.

It's like say "you do good use of operators if you're already famous otherwise you'll never be".

To me "good" and "bad use" simple means "combine coherently to for meaningful expressions or not".
Everything else is marketing, not science.
Operator overloading is nice, but you should understand basically it's just for the syntax candy.

Of course you can changes the meaning the way you ask. Probably every single C++ book shows at least a paragraph explaining why it's bad to foolish yourself in this way. Operators have much more important uses than that.

If you change the customary meaning of the operator, you should not forget that the bracket rules (operator precedence) are still governed by the operator itself, not its modified meaning.
 
Share this answer
 
Comments
Manfred Rudolf Bihy 18-Jan-11 16:11pm    
Yep, agreed! 5+
Espen Harlinn 18-Jan-11 16:40pm    
5+ (Now if we could alter operator precedence, we'd have a whole new playground for subtle tricks confusing the unwary, our coworkers, and friends)
Sergey Alexandrovich Kryukov 18-Jan-11 16:42pm    
Yes, like a contest "Most obfuscated C++ code" -- would be intriguing.
Overloading an operator is a tricky subject. The good (or bad it really depends) part is you can overload all these operators: http://msdn.microsoft.com/en-us/library/5tk49fh2(v=vs.80).aspx[^]

The problem is the benefit has to be greater than the confusion you can produce by doing this. If you decide to overload an operator and it significantly changes the usual semantic of that operator it has to be very well documented not only in the overloaded definition but also where it is used.
Since a change in the semantic of an operator can be quite obtrusive for the "normal" user it might be indicated to use it internally only.
But as I said before it really depends on the usefulness of it all.

My 2<samll>cts!

Hope this helps. If you have a concrete scenario in mind leave me a comment so we can discuss it.

Best regards,
Manfred
 
Share this answer
 
v2
Comments
Sergey Alexandrovich Kryukov 18-Jan-11 16:15pm    
Hm. Very mature notes - my 5.
I would say operators becomes tricky when applied or returned references, use memory allocation, etc.
Manfred Rudolf Bihy 18-Jan-11 16:20pm    
OMG! I didn't even think about that before (common sense maybe). Operators imposing side effects on the involved operands apart from the returned result. :shudders: :cringes:
Espen Harlinn 18-Jan-11 16:42pm    
5+ Imagine the entries to a c++ obfuscation contest :)
Manfred Rudolf Bihy 18-Jan-11 16:45pm    
Gives a whole new meaning to security by obscurity! :)
Sergey Alexandrovich Kryukov 18-Jan-11 21:18pm    
You're joking, but I saw people (and even worked with some of them, not just one) who really tried to manually make the code or data obscured and argues it helps security.
An overloaded operator is just a "function", so you can do your functions to do whatever you want.

But overloaded operator retain their role in expression (they will retain their nature of being prefix, postfix or infix, as well as their precedence).

So wherever you can write
A operator*(const A& a, const A& b) 
{ return a+b; }

(if it is that what you mean with "turning it into a +" )
will always retain a "multiplicative behavior" respect to +:

a + b * c
will be evaluated as
a + (b*c)
and will never become
(a+b)*c

Even if you revert the semantics of * and +.
 
Share this answer
 
v2
Comments
Espen Harlinn 19-Jan-11 9:03am    
5+ correct - so very correct :)
Manfred Rudolf Bihy 19-Jan-11 12:07pm    
This is actually a necessity. Changing operator precedence is a very tricky subject as it changes the way the AST (abstract syntax tree) is built. If we were able to change operator precedence it could be done in way that would break the parsers ability to identify expressions. I did some compiler building in my time and have run into a lot of problems with ambigous grammars that were easily resolved by introducing precedence (PREC) and associativity (ASSOC) definitions.
If these could be changed by the programmer the grammar could very easily be broken by doing stupid stuff.
This is one of the most comprehensive FAQs on this topic:

http://www.parashift.com/c++-faq-lite/operator-overloading.html[^]
 
Share this answer
 
Comments
Sergey Alexandrovich Kryukov 18-Jan-11 16:11pm    
Pretty good reference - a 5, there are a lot more sources -- just Google (but use critical thinking)
Manfred Rudolf Bihy 18-Jan-11 16:14pm    
Good link! 5+
Espen Harlinn 18-Jan-11 16:14pm    
5+ A nice uncomplicated overview. The is one thing though:
22.Use common sense
How common is common sense? cout << "Hello, I'm feeling dizzy, it feels like the world is shifting" << endl;
Nish Nishant 18-Jan-11 16:17pm    
Well the makers of C++ knew that common sense may not be all that common which is why they decided not to let programmers redefine operators on intrinsic types. A good thing totally! :-)
Espen Harlinn 18-Jan-11 16:26pm    
Wise, yes, but it would have been great fun :)
int result = 1+2;
cout << result << endl;
program output:
-1;
I overload operators for notational convenience for file/console output or making calculations, such as if I want to add to vectors or multiply matrices. You can overload * and many other operators, but you cannot change the # of inputs to the operator unfortunately. For instance [] cannot take multiple inputs for a matrix. Example: you must use A[1][2][3] instead of A[1,2,3].
 
Share this answer
 

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900