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

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;
returnStudent(plato);
// Plato studied under
// Socrates
// 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;
virtual void display() const;
};
// return name of window
// 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.