How to overload += -= *= etc

Question

Possible Duplicate:
C++ — How to overload operator+=?

I'm thinking about returning a reference to object when overloading += which is return by value in case of '+'?

see http://stackoverflow.com/questions/4581961/c-how-to-overload-operator — davka, Mar 03 '11 at 09:42
Yes, += should return by reference. See one of the MANY examples of previous questions on this topic for how to do it. — Lightness Races in Orbit, Mar 03 '11 at 09:48
I certainly intended to close this as a duplicate. I'll edit... — Cody Gray - on strike, Mar 03 '11 at 10:07
FWIW - I think this is significantly different to the possible duplicate (http://stackoverflow.com/questions/4581961) in that it (very vaguely) touches on the relationship between `+=` and `+`. — Tony Delroy, Mar 03 '11 at 10:48

score 4 · Answer 1 · answered Mar 03 '11 at 09:40

4

You overload those operators as in:

class X
{
  public:
    X& operator+=(const X& rhs) { ...; return *this; }
};

X operator+(X lhs, const X& rhs)
{
    return lhs += rhs;
}

answered Mar 03 '11 at 09:40

Tony Delroy

102,968
15
177
252

Could you please explain? As compound assignment `a+=b;` is equal to `a=a+b;`, how is it going to resolve which one to call? – Mahesh Mar 03 '11 at 09:42
I thought it was a '+' for sec but i know it needs to be += – user2231 Mar 03 '11 at 09:42
@Mahesh: "As compound assignment `a+=b;` is equal to `a=a+b;`". The compiler makes no such stipulation. Logically, you can define the relationship in either direction... here I define `+=` first, then `+` as a copy (notice lhs is **not** by reference) followed by a `+=`: this is quite common in C++. – Tony Delroy Mar 03 '11 at 09:45
@user2231: which `+` do you think needs to be a `+=`? Are you saying there's such a `+` in my code? (I only have one, and it is correct the way it is.) Or do you mean somewhere in your own code you had a `+` that needs to be a `+=`? Couldn't comment on that obviously ;-). – Tony Delroy Mar 03 '11 at 09:47
I have a question.. why should `+=` be a member of class? – user2231 Mar 03 '11 at 09:47
And operator + is missing the declaration as friend of class which confused me sorry. – user2231 Mar 03 '11 at 09:49
@user2231: `+=` can be a member or non-member, but often the "..." code that modifies the actual value of X needs access to private or protected data members. If not, you can make it a non-member ala `X& operator+=(X& lhs, const X& rhs) { ...; return lhs; }` – Tony Delroy Mar 03 '11 at 09:52
@user: Since `+=` always need to modify the rhs object, it makes sense to make it a member function. BUt AFAIK it does not have to be. – Björn Pollex Mar 03 '11 at 09:52
@user2231: `operator+` never needs to be a friend in the code in my answer, precisely because any private/protected member access can be performed inside the member `operator+=`. – Tony Delroy Mar 03 '11 at 09:53
@Space_COwbOy: just so... only if `operator+=` happened to use some other public method to do the modification for it, or only mutate public data (yikes), would it be equally convenient for it to be a non-member function. – Tony Delroy Mar 03 '11 at 09:55
Member vs. non-member for operator overloading is *nothing to do with accessing private data*. If you want to write this `+=` (or any other operator overload) as a non-member function which can access private data, simply write it as `public: friend X& operator+=(X& lhs, const X&rhs) { ...; return *this; }`. Member vs. non-member is to do with whether you want implicit conversions to be applied to the LHS of an expression involving the operator. Since this operator takes a non-const LHS, conversions are impossible anyway, so really it makes no difference. – Steve Jessop Mar 03 '11 at 10:52
@Steve: let me see if I can summarise that: "nothing to do with accessing private data" but you'd need to use `friend` otherwise, but it would relate to implicit conversion but that doesn't apply ;-) – Tony Delroy Mar 03 '11 at 11:09
@Tony: yes, I mean "nothing to do with it" in the sense that in general, if you decide whether to make your operator overloads members or not on that basis then you're Doing it Wrong, because there's another way of achieving the same thing without losing conversions. In this particular case, making it a member function does save you typing a few characters, which is about the closest to a significant difference between the two. From your first comment on the subject, it's "modifies the value" that makes it a sensible candidate for member function, not "needs access to private". – Steve Jessop Mar 03 '11 at 11:15

score 0 · Answer 2 · answered Mar 03 '11 at 09:37

0

+ should return a new value.

answered Mar 03 '11 at 09:37

Björn Pollex

75,346
28
201
283

score 0 · Answer 3 · answered Mar 03 '11 at 09:48

0

You can peacefully declare

class Class
{
public:
    void operator +=(const Class& obj) ;
} ;

and avoid cryptic code like a += b += c.

answered Mar 03 '11 at 09:48

Tugrul Ates

9,451
2
33
59

You could, but then the language doesn't avoid that for build in types and I've never heard anyone complain, and void would also prevent uses like `f(x += y)`, `while (n -= k)`, or `if ((n += 2).is_valid()) ...`. – Tony Delroy Mar 03 '11 at 10:51
@Tony - All those examples are equally cryptic in my opinion. Side effects are better presented in sole expressions. I try to avoid those with builtin types as well. Returning `void` for custom types only adds a favored compiler check in this rationale. – Tugrul Ates Mar 03 '11 at 11:23
yup, every programmer evolves their own stylistic compromises :-). Curious about yours though - how do you feel about `operator++()` and `++(int)`? Or `std::cout << a << b` and `if (std::cin >> x >> y)`...? – Tony Delroy Mar 03 '11 at 11:37
@Tony: I personally prefer leaving `++` and `--` to inner loops only and keeping main logic as explicit as possible. Stream operations are accepted as is by everyone, although it breaks the thumb rule of using operators with their builtin semantics :) I'm not really uncomfortable with them. – Tugrul Ates Mar 03 '11 at 11:50

How to overload += -= *= etc

3 Answers3