Item 15:  Have operator= return a reference to *this.

°Bjarne Stroustrup, the designer of C++, went to a lot of trouble to ensure that user-defined types would mimic the built-in types as closely as possible. That's why you can overload operators, write type conversion functions (see Item M5), take control of assignment and copy construction, etc. After so much effort on his part, the least you can do is keep the ball rolling.

Which brings us to assignment. With the built-in types, you can chain assignments together, like so:

int w, x, y, z;

w = x = y = z = 0;

As a result, you should be able to chain together assignments for user-defined types, too:

string w, x, y, z;               // string is "user-defined"
                                 // by the standard C++
                                 // library (see Item 49)

w = x = y = z = "Hello";

As fate would have it, the assignment operator is right-associative, so the assignment chain is parsed like this:

w = (x = (y = (z = "Hello")));

It's worthwhile to write this in its completely equivalent functional form. Unless you're a closet LISP programmer, this example should make you grateful for the ability to define infix operators:

w.operator=(x.operator=(y.operator=(z.operator=("Hello"))));

This form is illustrative because it emphasizes that the argument to w.operator=, x.operator=, and y.operator= is the return value of a previous call to operator=. As a result, the return type of operator= must be acceptable as an input to the function itself. For the default version of operator= in a class C, the signature of the function is as follows (see Item 45):

C& C::operator=(const C&);

You'll almost always want to follow this convention of having operator= both take and return a reference to a class object, although at times you may overload operator= so that it takes different argument types. For example, the standard string type provides two different versions of the assignment operator:

string&                            // assign a string
operator=(const string& rhs);      // to a string

string&                            // assign a char*
operator=(const char *rhs);        // to a string

Notice, however, that even in the presence of overloading, the return type is a reference to an object of the class.

A common error amongst new C++ programmers is to have operator= return void, a decision that seems reasonable until you realize it prevents chains of assignment. So don't do it.

Another common error is to have operator= return a reference to a const object, like this:

class Widget {
public:
  ...                                            // note
  const Widget& operator=(const Widget& rhs);    // const
  ...                                            // return
};                                               // type

The usual motivation is to prevent clients from doing silly things like this:

Widget w1, w2, w3;

...

(w1 = w2) = w3;         // assign w2 to w1, then w3 to
                        // the result! (Giving Widget's
                        // operator= a const return value
                        // prevents this from compiling.)

Silly this may be, but not so silly that it's prohibited for the built-in types:

int i1, i2, i3;

...

(i1 = i2) = i3;                // legal! assigns i2 to
                               // i1, then i3 to i1!

I know of no practical use for this kind of thing, but if it's good enough for the ints, it's good enough for me and my classes. It should be good enough for you and yours, too. Why introduce gratuitous incompatibilities with the conventions followed by the built-in types?

Within an assignment operator bearing the default signature, there are two obvious candidates for the object to be returned: the object on the left hand side of the assignment (the one pointed to by this) and the object on the right-hand side (the one named in the parameter list). Which is correct?

Here are the possibilities for a String class (a class for which you'd definitely want to write an assignment operator, as explained in Item 11):

String& String::operator=(const String& rhs)
{

  ...

return *this;            // return reference
                           // to left-hand object
}

String& String::operator=(const String& rhs)
{

  ...

return rhs;              // return reference to
                           // right-hand object
}

This might strike you as a case of six of one versus a half a dozen of the other, but there are important differences.

First, the version returning rhs won't compile. That's because rhs is a reference-to-const-String, but operator= returns a reference-to-String. Compilers will give you no end of grief for trying to return a reference-to-non-const when the object itself is const. That seems easy enough to get around, however — just redeclare operator= like this:

String& String::operator=(String& rhs)   { ... }

Alas, now the client code won't compile! Look again at the last part of the original chain of assignments:

x = "Hello";                     // same as x.op=("Hello");

Because the right-hand argument of the assignment is not of the correct type — it's a char array, not a String — compilers would have to create a temporary String object (via the String constructor — see Item M19) to make the call succeed. That is, they'd have to generate code roughly equivalent to this:

const String temp("Hello");      // create temporary

x = temp;                        // pass temporary to op=

Compilers are willing to create such a temporary (unless the needed constructor is explicit — see Item 19), but note that the temporary object is const. This is important, because it prevents you from accidentally passing a temporary into a function that modifies its parameter. If that were allowed, programmers would be surprised to find that only the compiler-generated temporary was modified, not the argument they actually provided at the call site. (We know this for a fact, because early versions of C++ allowed these kinds of temporaries to be generated, passed, and modified, and the result was a lot of surprised programmers.)

Now we can see why the client code above won't compile if String's operator= is declared to take a reference-to-non-const String: it's never legal to pass a const object to a function that fails to declare the corresponding parameter const. That's just simple const-correctness.

You thus find yourself in the happy circumstance of having no choice whatsoever: you'll always want to define your assignment operators in such a way that they return a reference to their left-hand argument, *this. If you do anything else, you prevent chains of assignments, you prevent implicit type conversions at call sites, or both.