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)
G. Samaras 
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.
I see your point. I did not think of that approach, but I think it is too much to provide getters for everything.