Overloading ==

This is driving me nuts and I'm here at work without my books to help out. For some reason I thought that one didn't need to overload the "==" operator when comparing two objects of the same class but I get an error saying that it isn't defined with left hand operator of myclass. So I tried overloading the operator in the class but I must be doing something wrong because it just becomes circular. Here is what I have:

Code:

---

bool board::operator ==(board& b)
{
        return (*this==b);
}

---

I have a feeling its something real easy to fix but for the life of me I can't figure it out.

how about return (privatemember1==b.privatemember1)&&(privatemember 2==b.privatemember2)&& so on;

Shouldn´t you compare the datamembers and not objects here like

Code:

---

bool board::operator ==(board& b)
{
if (datamember == b.datamember)//All conditions
  return true;
return false;
}

---

Thanks, but isn't there a better way? I really don't want to create functions that return each and every private member of the class.

You dont have to as members of the class ie bool operator ==(const class&)const has direct access to all private members so its just a case of ensuring that all data members are equal then returning true else return false. The logical && way is best as it offers short circuit evaluation returning false as soon as a condition is not met. So its reasonably efficient.

Learn something new every day. I knew it could access the members within *this but didn't know one could access the second objects datamembers directly as well.

I need to look in my books tonight because I could have sworn I've read of another way, but this is just fine as well. Thanks!

When you are overloading the == operator, you should use the == operator, to compare the data members of the class( which are built-in types ), and ofcourse return a bool, for example:

Code:

---

class myClass {
public:
    bool operator==( myClass &) const;
    //more members
private:
    int value1;
    int value2;
};

//definition of the operator==
bool myClass::operator==(myClass &right ) const{
{
    if ( value1 == right.value1 && value2 == right.value2 )
          return true;
    return false;
}

---

Hope it's clear now...

I'm not sure, and I'm still learning, but can you do something like this?

Code:

---

bool myClass::operator== (myClass & right) const {
        if(*this == right)
                return true;
        else
                return false;
}

---

>>I'm not sure, and I'm still learning, but can you do something like this?<<

No, that was what I was doing wrong. You basically end up with an unintentional recursive function that keeps calling itself over and over again because it keeps seeing the '=='!

okay. thanks.

Quote:

---

Originally posted by PJYelton
>>I'm not sure, and I'm still learning, but can you do something like this?<<

No, that was what I was doing wrong. You basically end up with an unintentional recursive function that keeps calling itself over and over again because it keeps seeing the '=='!

---

That's the whole idea, that's why I said in my post:

Quote:

---

you should use the == operator, to compare the data members of the class( which are built-in types ),

---

Shouldn't the == operator accept two arguments and not one? I've always seen == overloaded like this:

Code:

---

bool operator == (const myClass &lhs, const myClass &rhs)
{
        if(lhs.datamember1 == rhs.datamember1 && lhs.datamember2 == rhs.datamember3)
                return true;
        return false;
}

---

How should == be overloaded and why should it be done that way?

Quote:

---

Originally posted by joshdick
Shouldn't the == operator accept two arguments and not one? I've always seen == overloaded like this:

Code:

---

bool operator == (const myClass &lhs, const myClass &rhs)
{
        if(lhs.datamember1 == rhs.datamember1 && lhs.datamember2 == rhs.datamember3)
                return true;
        return false;
}

---

How should == be overloaded and why should it be done that way?

---

The overloaded == function should be a member function, because the left most operand is an object if the class you are overloading the == operator for it.

The call the compiler will generate is like this:
if you have:

Code:

---

object1 == object2;
//the compiler will generate the following:
object1.operator==(object2);

---

So it should be implemented as a member function...
The code you wrote implements it as a friend, and I'm not sure if it is going to work, because I didn't test it, but even if it does, you should not use it, because whenever you can use a member function you should not use a firend...

Note:
If you didn't get it, just tell me, I'll be glad to help...

Code:

---

bool SomeClass::operator == ( const SomeClass& other ) const
{
        if( this->Data == other.Data )
        {
                return true;
        }
        else
        {
                return false;
        }
}

---

Note the consts. Data is a primitive member of SomeClass. Obviously, all members that need to be checked should be included in this statement.

Quote:

---

Originally posted by ammar
The code you wrote implements it as a friend, and I'm not sure if it is going to work, because I didn't test it, but even if it does, you should not use it, because whenever you can use a member function you should not use a firend...

Note:
If you didn't get it, just tell me, I'll be glad to help...

---

Thanks for the offer of help. My confusion stems from the examples provided in my textbook. In those examples, arithmetic operators (+-*/), bool operators(==, >, etc.), and input/output of classes are done outside of the class as free (non-member) functions:confused: I looked through the whole textbook but couldn't find anything about the reserved word friend:mad:

Could you please explain it to me a bit, give a short example, when it should be used, and tell me why a member function is better than a friend function? I would really appreciate your help on this. I'm starting to write some classes on my own, and I don't want to screw them all up. Thanks in advance.

Friend functions allow other classes access to private data members. This is usually looked down upon because it violates the object oriented principle of encapsulation.

while it is often true that the arithmetic operators are implemented as non-member functions i cannot ever recall making comparison functions non-members. You really should invest in a much better text or two if you are serious about learning c++.
As a sidenote the reason that overloading >> and << for printing etc. is done as a non-member is because to be a member function they would have to be members of istream and ostream. This is obviously not possible. The most common implementation of them is just to forward a call to a member function that takes and returns a stream reference then no friendship need be granted either.

Quote:

---

Originally posted by Stoned_Coder
while it is often true that the arithmetic operators are implemented as non-member functions i cannot ever recall making comparison functions non-members. You really should invest in a much better text or two if you are serious about learning c++.

---

The textbook I have is what my programming class uses in school. Unfortunately, that class hasn't covered arrays, structs, or classes yet, so I'm on my own for now learning that stuff. I'm serious about learning to program, but I'm also seriously poor. I'm waiting for C++ for Dummies to be returned to the library, and some day when I have some time, I'd like to try to hunt down a free e-book. I know there's probably plenty of good links in past threads on this board. I just need to take the time to go looks them up. I guess I ought to just search around on my own to figure out this whole friend deal. Anyway, thanks for your help.

here are some links to some e-books.

http://www.cprogramming.com/cboard/s...ghlight=ebooks
http://www.tcfb.com/freetechbooks/bookcpp.html
http://www.ibiblio.org/obp/thinkCScpp/

hope it helps with the search.

Exactly as PJYelton, and stoned_coder said...
You should always keep this in mind: Whenever you can use a member function, use it, it's always better than firend functions.

Quote:

---

Originally posted by ammar
Exactly as PJYelton, and stoned_coder said...
You should always keep this in mind: Whenever you can use a member function, use it, it's always better than firend functions.

---

I'm sure that'd be great advice if only I knew what a friend function is. When I have time I'll take another look at "Thinking in C++" to see if friend functions are covered in there. Thanks for all of the help, everybody:cool:

A friend function is a function that has the right to access private and protected data members of the class it's has been declared as it's friend, for example:

Code:

---

class myClass{
friend void friendFunction(myClass &);
public:
//some members
private:
//int x;
};

void friendFunction(myClass &obj)
{
    obj.x = 5;    //because friendFunction is a friend of myClass
                        //it can access the private member x of class
                        //myClass
}

---

Hope friend functions are clear now, if they are not feel free to ask.

"Whenever you can make a function a member instead of a friend, you should"

This is not true for operator functions. Some are better implemented as non-member functions. You can usually do this without making them a friend, although sometimes making them a friend is an option. There are tradeoffs you have to evaluate. The main reason you don't make some operator functions member functions is to make them operate like built in types.

Get the two Effective C++ books by Scott Meyers. You shouldn't be without them.

Actually using a friend function makes sense, sometimes. For instance, if you are not comparing the same class type, ie. if it makes sense to compare MyClass to an int, you will want to define operator== two different ways:

Code:

---

class MyClass {
int somedata;
public:
MyClass(int i) { somedata = i; }

// some implementation goes here ...

// comparison operators:
bool MyClass::operator==(const int& i) const
{
    if ( somedata == i ) return true;
    else return false;
}

friend operator==(const int& i, const MyClass& mc)
{
    if ( mc.somedata == i ) return true;
    else return false;
}
};

// Now the user of the class can put the object either on the
// rhs or lhs of the operator==:

int main()
{
    MyClass mc(34);

    if ( mc == 34 ) {// do something
    }

    if ( 34 == mc ) { // this works too
    }

    return 0;
}

---

You can get that same functionality by using one == function and some form of implicit or explicit conversion too. Also, you can avoid making the function a friend by using an accessor function.

#include <iostream>

class Y
{
int i;
char ch;
public:
bool operator==(const Y &);
friend bool operator ==(const int &, const Y &);
};

bool Y::operator==(const Y &ob)
{
if(i == ob.i && ch == ob.ch)
return true;
else
return false;
}

bool operator==(const int &val, const Y &ob)
{
if(val == ob.i)
return true;
else
return false;
}

int main()
{
Y ob1, ob2;
int x = 20;

if(ob1 == ob2)
std::cout << "the two objects are equal .. that is "
"the datamembers of both the objects"
"hold similar values"
<< std::endl;

if(x == ob1)
std::cout << "the integer x is equal to the value"
" of the datamember i of the object ob1"
<< std::endl;

// imagine ob1 == ob2 this way.... ob1.==(ob2);
// in the sence an object can only call its member functions

// but x == ob1 cannot be looked in similar fashion since
// == is not a member function of int that can take an object
// of type class Y in the RHS
// in such situations where your LHS is not an object of the class
// whose object appears on the RHS
// you would have to take help of friend functions

// please note there are certain restrictions w.r.t operators
// that could be made as friends
// my aim here is just to help you give an idea as to when
// might need friend functions

Quote:

---

Originally posted by dynamic_cast
"Whenever you can make a function a member instead of a friend, you should"

This is not true for operator functions. Some are better implemented as non-member functions. You can usually do this without making them a friend, although sometimes making them a friend is an option. There are tradeoffs you have to evaluate. The main reason you don't make some operator functions member functions is to make them operate like built in types.

Get the two Effective C++ books by Scott Meyers. You shouldn't be without them.

---

Excuse me...
You are saying that: "This is not true for operator functions. Some are better implemented as non-member functions. You can usually do this without making them a friend,"...
That doesn't mean that: "Whenever you can make a function a member instead of a friend, you should"" is not true... The thing you are talking about is not realated to what I was talking about...

IfYouSaySo, ofcourse impelenting a function as a friend makes sence sometimes, but you should keep in mind that if you can implement it as a member function you should do so.

Quote:

---

Originally posted by ammar

IfYouSaySo, ofcourse impelenting a function as a friend makes sence sometimes, but you should keep in mind that if you can implement it as a member function you should do so.

---

Thats still wrong. There are many cases when you can but shouldn't.

Quote:

---

Originally posted by dynamic_cast
Thats still wrong. There are many cases when you can but shouldn't.

---

Maybe I'm wrong, but can you give me some examples, were I can use a member function and it's better to use a friend function.

Yeah sure. Ummm...the two off the top of my head are operator+ and operator<< and >>.

Both can be implemented as member functions. But it's better to implement opertaor+ as a toplevel function so that you can say '2 + class' as well as 'class + 2'. A memeber function would usually be able to do 'class + 2' by converting 2 to a class object implicity through the constructor or explicitly through an operator function. It won't be able to do '2 + class' though. ( 2.operator+(class) ) It won't convert the 2 in this case. Which brings up a good point. Anytime you want a conversation on both the left and right parameters you need a top level function. You could make it a member function...but it just wouldn't be a very good design.

operator>> and << need it because of convention. You could make them member functions, but then you'd have to write class >> cout and class << cin. Or youd have to overload the i and ostream class. Both bad ideas. So you use a top level function.

Other things prob come up to...but the point is, you can use a member function in every case here...but it's better to use a toplevel function. I didn't say a friend function...you can always use accessor memeber functions to avoid using a friend.

Sorry bout that rambled mess...it's 4 a.m. and I'm tired as hell.

edit:
O yeah...I wasn't really complaining about the friend part...but the statement is still untrue...even if you had to use a friend it would be better to in these exaples than using a memeber function. Fortuantley you don't have to use a friend because of accessor functions...though sometimes making them friends can have its benefits.

Well, I hope you have some sleep now, I know how does it feel, when it's 4 am!

In the example you gave about overloading the operator << and operator >> you cann't make them member functions because they should be members in the cout and cin objects, and that's not possible, and the only way is to make them friend functions...

And for the example: object + 2 and 2 + object, If you want to implement a them both as friend function you will have to write two functions, but would do it, by making the function 2 + object a friend function and the object + 2 function a member function...

About the statement I gave, I think it's a general programming principle...

But anyways I might be wrong, because I'm not experienced in C++...
Maybe we can make a thread about that, and ask for the advice of experiences programmers...

Quote:

---

[i]

In the example you gave about overloading the operator << and operator >> you cann't make them member functions because they should be members in the cout and cin objects, and that's not possible, and the only way is to make them friend functions...

[i]

---

You can make them members.
But you'd have to use the syntax 'class >> cout'
which is fine except it's not the same as how built in types work, which is confusing.

And no...you don't have to make two functions. You would most likeley take advantage of the implicit conversion of a constructor...or you could make an explicit conversion function. You don't NEED to make operator+ a friend, but maing it a member function is def the wrong way to go. It should always be a top level function.

just because of the class + 2, 2+ class issue, i'd make operator+ a friend function ..

Quote:

---

And for the example: object + 2 and 2 + object, If you want to implement a them both as friend function you will have to write two functions, but would do it, by making the function 2 + object a friend function and the object + 2 function a member function...

---

I don't think you need 2 functions for it ?

friend Class operator*(double, const Class &)

allows me to write (when double d, class c)

x= C * d as well as x = d *C ...
since the compiler sees it as
x=operator*(d, c) ..

which is the only use for friend-functions and the reason of their existence ...

a normal member function would be translated as
d *c
x=d.operator*(c) , making operator* a memberfunction of double which insn't possible and against the rules of OO

Correct me if I'm wrong but I don't see a way to be able to use associativity without friend functions

You can use accessor functions so that you don't need to make it a friend.

http://www.cs.rit.edu/~icss263/writing.classes/p8.html

If my quick read it correct accessor = getter/setter functions ?

Then please give me an example how to use it for c * d and d * c, because I would like to know.

edit : and why should I use accessor functions in stead of friend functions ?

Yes, it's getters and setters. You should use them instead of a friend function because people are anal and will ***** at you if you use friend functions...seriously, friend functions violate information hiding and the whole OOP thing (at least most say so), so using getters and setters is a better idea...sometimes a friend function would simplify things though.

Code:

---

class rational
{
public:
  rational(int num); //just initialize num
  rational(int num, int denom); //initialize num and denom
blah blah blah...
};

---

Okay, so you have a fractions function that can be intialized with a numerator and denominator or with just a numerator (you would make the denom default to 1 in the implementation).

now you have a top-level function that takes two rationals.

const rational operator+(rational first, rational second) //my best guess at this

Now you do '2 + rational' of course the scond rational works, but the first is an int...so your screwed...no, wait...the compiler knows if it supplies an int to the rational constructor it can make a rational. So it does and your all set. The same works for 'rational + 2'. You could also make a conversion operator function.

The compiler will only do conversions on both args if it's a top level function.

Anyway...sorry I'm not much of an explainer. And sorry if the code is screwed up. I don't really program. But hopefully you get the idea.