Item 22:  Prefer pass-by-reference to pass-by-value.

In C, everything is passed by value, and C++ honors this heritage by adopting the pass-by-value convention as its default. Unless you specify otherwise, function parameters are initialized with copies of the actual arguments, and function callers get back a copy of the value returned by the function.

As I pointed out in the Introduction to this book, the meaning of passing an object by value is defined by the copy constructor of that object's class. This can make pass-by-value an extremely expensive operation. For example, consider the following (rather contrived) class hierarchy:

class Person {
public:
  Person();                         // parameters omitted for
                                    // simplicity
  ~Person();

  ...

private:
  string name, address;
};

class Student: public Person {
public:
  Student();                        // parameters omitted for
                                    // simplicity
  ~Student();

  ...

private:
  string schoolName, schoolAddress;
};

Now consider a simple function returnStudent that takes a Student argument (by value) and immediately returns it (also by value), plus a call to that function:

Student returnStudent(Student s) { return s; }

Student plato;                      // Plato studied under
                                    // Socrates

returnStudent(plato);               // call returnStudent

What happens during the course of this innocuous-looking function call?

The simple explanation is this: the Student copy constructor is called to initialize s with plato. Then the Student copy constructor is called again to initialize the object returned by the function with s. Next, the destructor is called for s. Finally, the destructor is called for the object returned by returnStudent. So the cost of this do-nothing function is two calls to the Student copy constructor and two calls to the Student destructor.

But wait, there's more! A Student object has two string objects within it, so every time you construct a Student object you must also construct two string objects. A Student object also inherits from a Person object, so every time you construct a Student object you must also construct a Person object. A Person object has two additional string objects inside it, so each Person construction also entails two more string constructions. The end result is that passing a Student object by value leads to one call to the Student copy constructor, one call to the Person copy constructor, and four calls to the string copy constructor. When the copy of the Student object is destroyed, each constructor call is matched by a destructor call, so the overall cost of passing a Student by value is six constructors and six destructors. Because the function returnStudent uses pass-by-value twice (once for the parameter, once for the return value), the complete cost of a call to that function is twelve constructors and twelve destructors!

In fairness to the C++ compiler-writers of the world, this is a worst-case scenario. Compilers are allowed to eliminate some of these calls to copy constructors. (The °C++ standard — see Item 50 — describes the precise conditions under which they are allowed to perform this kind of magic, and Item M20 gives examples). Some compilers take advantage of this license to optimize. Until such optimizations become ubiquitous, however, you've got to be wary of the cost of passing objects by value.

To avoid this potentially exorbitant cost, you need to pass things not by value, but by reference:

const Student& returnStudent(const Student& s)
{ return s; }

This is much more efficient: no constructors or destructors are called, because no new objects are being created.

Passing parameters by reference has another advantage: it avoids what is sometimes called the "slicing problem." When a derived class object is passed as a base class object, all the specialized features that make it behave like a derived class object are "sliced" off, and you're left with a simple base class object. This is almost never what you want. For example, suppose you're working on a set of classes for implementing a graphical window system:

class Window {
public:
  string name() const;             // return name of window
  virtual void display() const;    // draw window and contents
};

class WindowWithScrollBars: public Window {
public:
  virtual void display() const;
};

All Window objects have a name, which you can get at through the name function, and all windows can be displayed, which you can bring about by invoking the display function. The fact that display is virtual tells you that the way in which simple base class Window objects are displayed is apt to differ from the way in which the fancy, high-priced WindowWithScrollBars objects are displayed (see Items 36, 37, and M33).

Now suppose you'd like to write a function to print out a window's name and then display the window. Here's the wrong way to write such a function:

// a function that suffers from the slicing problem
void printNameAndDisplay(Window w)
{
  cout << w.name();
  w.display();
}

Consider what happens when you call this function with a WindowWithScrollBars object:

WindowWithScrollBars wwsb;

printNameAndDisplay(wwsb);

The parameter w will be constructed — it's passed by value, remember? — as a Window object, and all the specialized information that made wwsb act like a WindowWithScrollBars object will be sliced off. Inside printNameAndDisplay, w will always act like an object of class Window (because it is an object of class Window), regardless of the type of object that is passed to the function. In particular, the call to display inside printNameAndDisplay will always call Window::display, never WindowWithScrollBars::display.

The way around the slicing problem is to pass w by reference:

// a function that doesn't suffer from the slicing problem
void printNameAndDisplay(const Window& w)
{
  cout << w.name();
  w.display();
}

Now w will act like whatever kind of window is actually passed in. To emphasize that w isn't modified by this function even though it's passed by reference, you've followed the advice of Item 21 and carefully declared it to be const; how good of you.

Passing by reference is a wonderful thing, but it leads to certain complications of its own, the most notorious of which is aliasing, a topic that is discussed in Item 17. In addition, it's important to recognize that you sometimes can't pass things by reference; see Item 23. Finally, the brutal fact of the matter is that references are almost always implemented as pointers, so passing something by reference usually means really passing a pointer. As a result, if you have a small object — an int, for example — it may actually be more efficient to pass it by value than to pass it by reference.