Effective C++ by Scott Meyers (Short Summary)
  • Introduction
  • Chapter 1 - Accustoming Yourself to C++
    • Item 1 - View C++ as a federation of languages.
    • Item 2 - Prefer consts, enums, and inlines to #defines.
    • Item 3 - Use const whenever possible.
    • Item 4 - Make sure that objects are initialized before they’re used.
  • Chapter 2 - Constructors, Destructors, and Assignment Operators
    • Item 5 - Know what functions C++ silently writes a calls.
    • Item 6 - Explicitly disallow the use of compiler-generated functions you do not want.
    • Item 7 - Declare destructors virtual in polymorphic base classes.
    • Item 8 - Prevent exceptions from leaving destructors.
    • Item 9 - Never call virtual functions during construction or destruction.
    • Item 10 - Have assignment operators return a reference to *this.
    • Item 11 - Handle assignment to self in operator=.
    • Item 12 - Copy all parts of an object.
  • Chapter 3 - Resource Management
    • Item 13 - Use objects to manage resources.
    • Item 14 - Think carefully about copying behavior in resource-managing classes.
    • Item 15 - Provide access to raw resources in resource-managing classes.
    • Item 16 - Use the same form in corresponding uses of new and delete.
    • Item 17 - Store newed objects in smart pointers in standalone statements.
  • Chapter 4 - Designs and Declarations
    • Item 18 - Make interfaces easy to use correctly and hard to use incorrectly.
    • Item 19 - Treat class design as type design.
    • Item 20 - Prefer pass-by-reference-to-const to pass-by-value.
    • Item 21 - Don't try to return a reference when you must return an object.
    • Item 22 - Declare data members private.
    • Item 23 - Prefer non-member non-friend functions to member functions.
    • Item 24 - Declare non-member functions when type conversions should apply to all parameters.
    • Item 25 - Consider support for a non-throwing swap.
Powered by GitBook
On this page
  1. Chapter 2 - Constructors, Destructors, and Assignment Operators

Item 11 - Handle assignment to self in operator=.

An assignment to self occurs when an object is assigned to itself:

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, Derived* pd);        //rb and *pd might actually be the same object,

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 implementation of operator=
{
    delete pb;                    // stop using current bitmap
    pb = new Bitmap(*rhs.pb);     // start using a copy of rhs's bitmap
    return *this;
}

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)         // identity test: if a self-assignment,
        return *this;         // do nothing.
        
    delete pb;
    pb = new Bitmap(*rhs.pb);
    return *this;
}

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. 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);      // point pb to a copy of rh's bitmap
    delete pOrig;                  // delete the original pb
    
    return *this;
}

Now, if "new Bitmap" throws an exception, pb (and the Widget it's inside of) remain unchanged. Even without the identity test, this code handles assignment to self, because we make a copy of the original bitmap.

Things to Remember

  • Make sure operator= is well-behaved when an object is assigned to itself. Techniques include comparing addresses of source and target objects, careful statement ordering, and copy-and-swap.

  • Make sure that any function operating on more than one object behaves correctly if two or more of the objects are the same.

1: Probably. C++ implementations are permitted to change the value of a deleted pointer (e.g., to null or some other special bit pattern).

PreviousItem 10 - Have assignment operators return a reference to *this.NextItem 12 - Copy all parts of an object.

Last updated 3 years ago

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 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!

This works, because it is self-assignment safe, but it is exception-unsafe. In particular, if the new Bitmap expression yields an exception (either because there is insufficient memory for 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.

1
1