Overloading equality operator (C++)

eq.cpp

#include <iostream>
using namespace std;

class A{
    // Default scope is private
    int x;
    int y;
    int z;
public:
    A(const int X, const int Y, const int Z) {
        x = X; y = Y; z = Z;
    }
    
    const int getX() const { return x; }
    const int getY() const{ return y; }
    const int getZ() const { return z; }
    
    // Overload equality operator
    bool operator==(const A& s) {
        if( s.getX() == x && s.getY() == y && s.getZ() == z)
            return true;
        else
            return false;
    }
};

int main()
{
    A a(1,1,1), b(2,2,2);
    if(a == b)
        cout << "a and b are equal" << endl;
    else
        cout << "a and b are NOT equal" << endl;
}

This code was developed by me, G. Samaras.

A nonmember, non-friend version, that Josh kindly suggested (read more in the comments below):

bool operator == (const A& lhs, const A& rhs) {
    return lhs.getX() == rhs.getX() && lhs.getY() == rhs.getY() 
           && lhs,getZ() && rhs.getZ(); 
}

Have questions about this code? Comments? Did you find a bug? Let me know!😀
Page created by G. (George) Samaras (DIT)

4 thoughts on “Overloading equality operator (C++)

  1. In this case, I would prefer a nonmember, non-friend version.

    bool operator == (const A& lhs, const A& rhs) { return lhs.getX() == rhs.getX() && lhs.getY() == rhs.getY() && lhs,getZ() && rhs.getZ(); }

    Code is actually more encapsulated if you try to do it this way. The less functions actually have access to state, the fewer member functions there are to check if something breaks the object.

    • In the case of the equality operator?

      If we are to go with this approach, a generic approach would be nice. But this can not happen, since you do not know what fields to check.

      So, in a project with many classes, your approach would produce as many overloads as the classes, which is the same result (in number) as the approach of having the overload as a member function.

      The trade-off of your approach is, in first glance, that you get more encapsulated code, but you decrease the readability of the code, because people are used to check the class, in order to find out what’s up with an instance of this class.

      It would be nice to have this choice as an option too, thus I will upload it.😉

      • If you are going to provide getters for all of the stuff that matters in equality, then you can do it this way. As the class designer, you can decide what manner of encapsulation is possible. I will admit in most classes, only friendship is the most encapsulated possibility, and that’s fine.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s