Item 11: Handle assignment to self in operator=

class Widget { ... };



Widget w;

...



w = w;                                   // assignment to self

This looks silly, but it's legal, so rest assured that clients will do it. Besides, assignment isn't always so recognizable. For example,

a[i] = a[j];                                      // potential assignment to self

is an assignment to self if i and j have the same value, and

*px = *py;                                        // potential assignment to self

is an assignment to self if px and py happen to point to the same thing. These less obvious assignments to self are the result of aliasing: having more than one way to refer to an object. In general, code that operates on references or pointers to multiple objects of the same type needs to consider that the objects might be the same. In fact, the two objects need not even be declared to be of the same type if they're from the same hierarchy, because a base class reference or pointer can refer or point to an object of a derived class type:

class Base { ... };



class Derived: public Base { ... };



void doSomething(const Base& rb,                   // rb and *pd might actually be

                 Derived* pd);                      // the same object

If you follow the advice of Items 13 and 14, you'll always use objects to manage resources, and you'll make sure that the resource-managing objects behave well when copied. When that's the case, your assignment operators will probably be self-assignment-safe without your having to think about it. If you try to manage resources yourself, however (which you'd certainly have to do if you were writing a resource-managing class), you can fall into the trap of accidentally releasing a resource before you're done using it. For example, suppose you create a class that holds a raw pointer to a dynamically allocated bitmap:

class Bitmap { ... };



class Widget {

  ...



private:

  Bitmap *pb;                                     // ptr to a heap-allocated object

};

Here's an implementation of operator= that looks reasonable on the surface but is unsafe in the presence of assignment to self. (It's also not exception-safe, but we'll deal with that in a moment.)

Widget&

Widget::operator=(const Widget& rhs)              // unsafe impl. of operator=

{

  delete pb;                                      // stop using current bitmap

  pb = new Bitmap(*rhs.pb);                       // start using a copy of rhs's bitmap



  return *this;                                   // see Item 10

}

The self-assignment problem here is that inside operator=, *this (the target of the assignment) and rhs could be the same object. When they are, the delete not only destroys the bitmap for the current object, it destroys the bitmap for rhs, too. At the end of the function, the Widget — which should not have been changed by the assignment to self — finds itself holding a pointer to a deleted object!

The traditional way to prevent this error is to check for assignment to self via an identity test at the top of operator=:

Widget& Widget::operator=(const Widget& rhs)

{

  if (this == &rhs) return *this;   // identity test: if a self-assignment,

                                    // do nothing

  delete pb;

  pb = new Bitmap(*rhs.pb);



  return *this;

}

This works, but I mentioned above that the previous version of operator= wasn't just self-assignment-unsafe, it was also exception-unsafe, and this version continues to have exception trouble. In particular, if the "new Bitmap" expression yields an exception (either because there is insufficient memory for the allocation or because Bitmap's copy constructor throws one), the Widget will end up holding a pointer to a deleted Bitmap. Such pointers are toxic. You can't safely delete them. You can't even safely read them. About the only safe thing you can do with them is spend lots of debugging energy figuring out where they came from.

Happily, making operator= exception-safe typically renders it self-assignment-safe, too. As a result, it's increasingly common to deal with issues of self-assignment by ignoring them, focusing instead on achieving exception safety. Item 29 explores exception safety in depth, but in this Item, it suffices to observe that in many cases, a careful ordering of statements can yield exception-safe (and self-assignment-safe) code. Here, for example, we just have to be careful not to delete pb until after we've copied what it points to:

Widget& Widget::operator=(const Widget& rhs)

{

  Bitmap *pOrig = pb;               // remember original pb

  pb = new Bitmap(*rhs.pb);         // make pb point to a copy of *pb

  delete pOrig;                     // delete the original pb



  return *this;

}

Now, if "new Bitmap" throws an exception, pb (and the Widget it's inside of) remains unchanged. Even without the identity test, this code handles assignment to self, because we make a copy of the original bitmap, delete the original bitmap, then point to the copy we made. It may not be the most efficient way to handle self-assignment, but it does work.

If you're concerned about efficiency, you could put the identity test back at the top of the function. Before doing that, however, ask yourself how often you expect self-assignments to occur, because the test isn't free. It makes the code (both source and object) a bit bigger, and it introduces a branch into the flow of control, both of which can decrease runtime speed. The effectiveness of instruction prefetching, caching, and pipelining can be reduced, for example.

An alternative to manually ordering statements in operator= to make sure the implementation is both exception- and self-assignment-safe is to use the technique known as "copy and swap." This technique is closely associated with exception safety, so it's described in Item 29. However, it's a common enough way to write operator= that it's worth seeing what such an implementation often looks like:

class Widget {

  ...

  void swap(Widget& rhs);   // exchange *this's and rhs's data;

  ...                       // see Item 29 for details

};



Widget& Widget::operator=(const Widget& rhs)

{

  Widget temp(rhs);             // make a copy of rhs's data



  swap(temp);                   // swap *this's data with the copy's

  return *this;

}

A variation on this theme takes advantage of the facts that (1) a class's copy assignment operator may be declared to take its argument by value and (2) passing something by value makes a copy of it (see Item 20):

Widget& Widget::operator=(Widget rhs)   // rhs is a copy of the object

{                                       // passed in — note pass by val



  swap(rhs);                            // swap *this's data with

                                        // the copy's



  return *this;

}

Personally, I worry that this approach sacrifices clarity at the altar of cleverness, but by moving the copying operation from the body of the function to construction of the parameter, it's a fact that compilers can sometimes generate more efficient code.