0

So, we are studying about the topics I mentioned in the title and it seems like I got it all pretty confused.

Let's say for example that I have this class:

class Complex { 
    double re;
    double im;
public:
 Complex(double r = 0, double i = 0);
}

Now, I want to be able to do some basic arithmetic's with complex numbers.

For example, let's say I want to add one complex number to another, for this I can add the following method:

class Complex { 
    double re;
    double im;
public:
 Complex(double r = 0, double i = 0);
 Complex& operator+=(const Complex& c);
}

And it will be defined like this:

Complex& Complex::operator+=(const Complex& c) {
    re += c.re;
    im += c.im;
    return *this;
}

However, when I want to compare two complex numbers, to my understanding things become trickier, and for some reason which I am unable to understand we will have to add "friend" in the before we add the declaration of the function.

The function is defined like this:

bool operator==(const Complex& a, const Complex& b) {
    return a.re == b.re && a.im == b.im;
}

So my questions are:

  1. Why don't we add "friend" before declaring the operator += as well? I mean both times we use the same variables in the class.

  2. How is it possible to determine where friend should be used?

איתן לוי
  • 433
  • 1
  • 3
  • 9
  • The `operator+=` function is a *member* function of the `Complex` class. `operator==` is a *non*-member function. That makes a very big difference. And I'm sorry if sounding rude, but you really should take some time with [a few good books](https://stackoverflow.com/questions/388242/the-definitive-c-book-guide-and-list/388282#388282) as they should have taught you the difference. – Some programmer dude Jun 04 '19 at 18:53
  • [What are the basic rules and idioms for operator overloading?](https://stackoverflow.com/questions/4421706/what-are-the-basic-rules-and-idioms-for-operator-overloading) – R Sahu Jun 04 '19 at 18:53
  • `operator +=` is a member function. It already has access to private members. The free-function `operator ==` is *not* a member, and therefore must be friended if accessing private members (variables or functions). – WhozCraig Jun 04 '19 at 18:53
  • Why is += a member and == is not? – איתן לוי Jun 04 '19 at 18:56
  • For starters, assignment operators can't be non-member functions. – Some programmer dude Jun 04 '19 at 18:57
  • It's all in the duplicate: do study it. (Not a poor question by the way, just already answered.) – Bathsheba Jun 04 '19 at 18:57
  • @איתןלוי Because you decided to make one a member and make another a non-member. You could have chosen to use `Complex& operator==(const Complex&) const;` instead and make it a member. Most operators for `class` types can be implemented *either* as a member *or* as a non-member. It's up to you. – François Andrieux Jun 04 '19 at 18:58
  • Is there a reason I shouldn't define the == operator as a member? We were told not to do it with symmetrical operations (such as == or +) but I couldn't really understand the reason. – איתן לוי Jun 04 '19 at 19:00
  • Note that you don't necessarily *need* to make your `operator==` a `friend`. Presumably, your actual `Complex` class will have some way of returning the imaginary and real parts. If it does, `operator==` could very well use those instead and not need access to the `private` members at all. – François Andrieux Jun 04 '19 at 19:00
  • @איתןלוי Not really, there isn't much of a difference if you will make them `friend` anyway. Though operators like `operator+` are usually easier to implement in terms of `operator+=`, so you sometimes see an intrusive member `operator+=` and then a free non-`friend` operator `operator+` that just uses the publicly available `operator+=`. – François Andrieux Jun 04 '19 at 19:01

0 Answers0