If + is overloaded, += will be automatically overloaded?

[northfly]

We know we can overload the operator + when defining a new class, but if the + is overloaded, the += will be automatically overloaded or not? Do we need to specify it manually? Thanks.

[sohguanh]

Edit: Strange you need define += why is this so ?!?!

  class Test {
    public:
    Test& operator+(Test&) {}
    Test& operator=(Test&) {}
    Test& operator+=(Test&) {} //this is needed else cannot compile!!!!
  };

  Test obj1, obj2;
  obj1 += obj2;

Good question. I would think += imply we need to overload + and = so compiler can figure out += is an operator+ followed by operator= ?

Actually very easy to test out. You write simple class that overload + only. Then in the main program invoke your class with += and see compiler complain or not :P

[Athar]

operator= is the only operator that is provided by the compiler.
That's a good thing too... if operator+= was automatically implemented as a combination of operator+ and operator=, you might run into performance problems with large and complex object, seeing that a proper implementation of operator+ creates a temporary object, even though there is no need for operator+= to do that. If anything, it might make more sense to automatically have operator+ implemented using operator+=, because in most cases operator+ is defined as follows anyway:

Type operator+(const Type& rhs) const
{
  Type obj(*this);
  obj+=rhs;
  return obj;
}

[h9uest]

No matter what version of compiler you're using, it does not automatically overload += (and it should not. I'll be really surprised if any vendor does that).

The reason is:
for compilers, an operator is just a mapping from some domain to another. In their eyes, + has little to do with +=, although they have same default domains of inner-supported types, like int, double ... whatever, and similar semantics. They're separate things.

Now, you overload +, the mapping is changed. But since they're separate things to compilers, and compilers aren't so intelligent (at least for now) to associate this change made by you to some potential changes of another mapping. Current compilers don't support that.

A slightly more interesting question would be, would vendors start to support something like this in the future? From my design philosophy, they shouldn't.
1. C++/C both have the reputation for power and flexibility. Adding the feature seems to limit programmers' wills, thus damaging the reputation.
2. if you do auto-overloading for + and +=, are you going to do the same for all other compound operators? if yes, costs are great and most of them are not really necessary; if no, cohesion is broken.
3. this is sort of like writing a firmware virus --- once you get it done, it's great; but in today's "time is money" society, who is going to sit in front of their desk for weeks or even months just for one virus? just hit and run, and it's already enough.

[ernestus]

Overloading + does not overload += for the simple reason they are two different operators. If any compiler does that, then they have a problem.

Cheers