implicit assignment operators

Question

If I have an operator overload on my class, is the assignment version of the operator implicitly created as well?

class square{
   square operator+(const square& B);
   void operator=(const square& B);
};

As in, can I then call

square A, B;
A += B;

with the compiler implicitly deciding to call operator+ then operator=?

Operator overloading is one of the best ways of making code unreadable. According to the [Google C++ Style Guide](http://google-styleguide.googlecode.com/svn/trunk/cppguide.html#Operator_Overloading): "In general, do not overload operators. You can define ordinary functions like Equals() if you need them." — msw, Mar 07 '15 at 21:44
It is so much nicer though, when creating classes that are to be used to represent numbers to be able to read the code in a familiar format, it is a matter of; A = A.add(B).div(C).mul(D) vs A = (A + B) / C * D — user4578093, Mar 08 '15 at 05:56

Emil Laine · Answer 1 · 2015-03-07T21:43:52.023

5

No, += must be defined explicitly.

As a side note, operator+ should usually create a new object:

square operator+(const square& B);

And operator= should return a reference to *this:

square& operator=(const square& B);

Also worth noting that operator+ is usually implemented in terms of operator+=, i.e. operator+ calls operator+= on the new copy.

edited Mar 07 '15 at 21:43

answered Mar 07 '15 at 21:37

Emil Laine

41,598
9
101
157

as it does in all my implimentations, but i leave operator= void usually, as i have never used a multiple assignment – user4578093 Mar 08 '15 at 05:47
also, that refrence was not supposed to be there – user4578093 Mar 08 '15 at 05:49
1

Even though you have not used it *so far*, it doesn't hurt to have it there. The compiler will optimize it away where you aren't using it. – Emil Laine Mar 08 '15 at 11:39
That is very good to know! My concern really was about the cost of moving data even when I would never use it, thank you! – user4578093 Mar 08 '15 at 17:28
@user4578093 Don't concern yourself with stuff like that, remember that ["premature optimization is the root of all evil"](http://stackoverflow.com/a/385529/3425536). – Emil Laine Mar 08 '15 at 17:40
I thought that role was filled by money, but maybe money and premature optimization have a root network or something – user4578093 Mar 08 '15 at 18:59
That too. Both very evil. – Emil Laine Mar 08 '15 at 19:04

Pradhan · Accepted Answer · 2015-03-08T08:31:19.833

No, the operators aren't implicitly defined. However, boost/operators.hpp defines useful helper templates to avoid boiler-plate code. Example from their docs :

If, for example, you declare a class like this:

class MyInt
    : boost::operators<MyInt> {
    bool operator<(const MyInt& x) const;
    bool operator==(const MyInt& x) const;
    MyInt& operator+=(const MyInt& x);
    MyInt& operator-=(const MyInt& x);
    MyInt& operator*=(const MyInt& x);
    MyInt& operator/=(const MyInt& x);
    MyInt& operator%=(const MyInt& x);
    MyInt& operator|=(const MyInt& x);
    MyInt& operator&=(const MyInt& x);
    MyInt& operator^=(const MyInt& x);
    MyInt& operator++();
    MyInt& operator--(); };

then the operators<> template adds more than a dozen additional operators, such as operator>, <=, >=, and (binary) +. Two-argument forms of the templates are also provided to allow interaction with other types.

In addition, there is also support for implicitly "deducing" just a specific set of operators using arithmetic operator templates.

Paul Rooney · Answer 3 · 2015-03-08T01:26:56.380

3

No operator+= is its own operator and must be defined explicitly.

Note that operator+ should return a new object rather than a reference to the original object. The original object should be left unchanged.

operator+= should return the original object with the required value added. operator+= is often preferable as it eliminates a temporary object.

edited Mar 08 '15 at 01:26

answered Mar 07 '15 at 21:39

Paul Rooney

20,879
9
40
61

implicit assignment operators

3 Answers3