4

I recently have discovered the wonderful capability of C++ to allow programmers to overload operations on classes they create. As a way to venture into this topic, I decided to try making my own vector class.

As a little test to satisfy my curiousity, I recently did the following to overload the equality operators for my class:

 95 bool Vect::operator==(const Vect& rhs){
 96     return this->getCoord() == rhs.getCoord()
 98 }
 99 
100 bool Vect::operator!=(const Vect& rhs){
101     return !(*this == rhs);
102 }

This compiles and works correctly. However, I had a question about whether or not this was good/bad practice (and why!). I do not want to fall into the habit of doing this if it's a bad one, or encourage myself to keep using this if its a good one.

May
  • 77
  • 1
  • 10
  • 1
    You are using the feature correctly. It may not be provided if it is not good. operators can be used in lot of ways and code becomes elegant. It allows to compare/operate your own specialized ways. – Satish Chalasani Jul 23 '15 at 03:17
  • 1
    What if `operator==` were more complex? Would you want to implement `operator !=` by rewriting `==` and possibly make a mistake when trying to figure out the inverse? Believe it or not, I do see code written where the (naive) programmer sat down and tried to write `!=` by turning `==` "inside out", when all that needed to be done is place a single `!` character. – PaulMcKenzie Jul 23 '15 at 03:21
  • 3
    [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself) principles would *insist* that this is a good practice. Writing the same logic several times may introduce new bugs, and if you ever need to *change that logic*, you don't need to guess all the places that you implemented it. You're doing well! – Drew Dormann Jul 23 '15 at 03:24
  • 2
    Also, the same can be said for other relational operators. The only relational operators that you need "full code" for are `==` and `<`. All other relational operators ( `<=`, `>`, `!=`, `>=`) can be derived from these two. – PaulMcKenzie Jul 23 '15 at 03:26
  • You might consider implementing these operators as [non-member, non-friend functions](http://stackoverflow.com/a/1055889/3422652). – Chris Drew Jul 23 '15 at 07:59
  • FWIW [Boost Operators](http://www.boost.org/doc/libs/1_57_0/libs/utility/operators.htm) were created specifically because good operator overloading commonly involves multiple operators implemented in terms of each other and the author wanted to reduce the amount of boilerplate code. – Jay Miller Jul 23 '15 at 17:45

1 Answers1

1

There is nothing bad about operator overloading, it is a good practice.

Operator overloading helps you write clean and easily understandable code and makes editing process easier.

PS: As you said, you recently came across operator overloading, this might help you understand some rules and limitations of it.

EDIT : Using overloaded operator to overload other operator is okay. But it makes two function calls instead of one, which is not advisable considering performance. But it does not affect that much.

Milan Patel
  • 422
  • 4
  • 12
  • Thanks for the post. However, I know that operator overloading is a useful practice, but what I was inquiring about was whether or not using the overloaded operator for one operator (in this case, "==") to define another ("!=") was good practice. Thanks for the reference. – May Jul 23 '15 at 06:55
  • On another note however, I am unsure whether I should accept this as an answer? It did not address my question, but it is the only "answer" given (besides the comments of course, which I can't accept). Should I leave this question unanswered? – May Jul 23 '15 at 06:56
  • My bad! I missunderstood the question. I have made edit in my answer. Accepting the answer is your call, if it is helpful then accept or don't. – Milan Patel Jul 23 '15 at 07:12
  • Absolutely no problem -- we all make mistakes, whether in programming or on SO. I'll accept the answer, since it very concisely and thoroughly answers the question, and also includes a caveat to the practice. – May Jul 23 '15 at 07:14