Item 26:
Postpone
variable definitions as long as possible.
Whenever you define a variable of a type with a constructor or destructor, you incur the cost of construction when control
reaches
the variable's definition, and you incur the cost of destruction when the variable goes out of scope. There's a cost associated with unused
variables
, so you want to avoid them whenever you can.
You're probably thinking that you never define unused variables, but you may need to think again. Consider the following function, which returns an encrypted version of a password, provided the password is long enough. If the password is too short, the function throws an exception of type
logic_error
, which is defined in the standard C++ library (see Item 54):
// this function defines the variable "encrypted" too soon
std::string encryptPassword(const std::string& password)
{
using namespace std;
string encrypted;
if (password.length() < MinimumPasswordLength) {
throw logic_error("Password is too short");
}
... // do whatever is necessary to place an
// encrypted version of password in encrypted
return encrypted;
}
The object
encrypted
isn't
completely
unused in this function, but it's unused if an exception is thrown. That is, you'll pay for the construction and destruction of
encrypted
even if
encryptPassword
throws an exception. As a result, you're better off postponing
encrypted
's definition until you
know
you'll need it:
// this function postpones encrypted's definition until it's truly necessary
std::string encryptPassword(const std::string& password)
{
using namespace std;
if (password.length() < MinimumPasswordLength) {
throw logic_error("Password is too short");
}
string encrypted;
... // do whatever is necessary to place an
// encrypted version of password in encrypted
return encrypted;
}
This code still isn't as tight as it might be, because
encrypted
is defined without any initialization arguments. That means its default constructor will be used. In many cases, the first thing you'll do to an object is give it some value, often via an assignment. Item 4 explains why default-constructing an object and then assigning to it is less efficient than initializing it with the value you really want it to have. That analysis applies here, too. For example, suppose the hard part of
encryptPassword
is performed in this function:
void encrypt(std::string& s); // encrypts s in place
Then
encryptPassword
could be implemented like this, though it wouldn't be the best way to do it:
// this function postpones encrypted's definition until
// it's necessary, but it's still needlessly inefficient
std::string encryptPassword(const std::string& password)
{
... // check length as above
std::string encrypted;
// default-construct encrypted
encrypted = password;
// assign to encrypted
encrypt(encrypted);
return encrypted;
}
A preferable approach is to initialize
encrypted
with
password
, thus skipping the pointless and
potentially
expensive default construction:
// finally, the best way to define and initialize encrypted
std::string encryptPassword(const std::string& password)
{
... // check length
std::string encrypted(password);
// define and initialize
// via copy constructor
encrypt(encrypted);
return encrypted;
}
This suggests the real meaning of "as long as possible" in this Item's title. Not only should you postpone a variable's definition until right before you have to use the variable, you should also try to postpone the definition until you have initialization arguments for it. By doing so, you avoid constructing and destructing unneeded objects, and you avoid unnecessary default constructions. Further, you help document the purpose of variables by initializing them in contexts in which their meaning is clear.
"But what about
loops
?" you may
wonder
. If a variable is used only inside a loop, is it better to define it outside the loop and make an assignment to it on each loop iteration, or is it be better to define the variable inside the loop? That is, which of these general structures is better?
//
Approach A
: define outside loop //
Approach B
: define inside loop
Widget w;
for (int i = 0; i < n; ++i){ for (int i = 0; i < n; ++i) {
w =
some value dependent on i;
Widget w(
some value dependent on i
);
... ...
} }
Here I've switched from an object of type
string
to an object of type
Widget
to avoid any preconceptions about the cost of performing a construction, destruction, or assignment for the object.
In terms of
Widget
operations, the costs of these two approaches are as
follows
:
For classes where an assignment costs less than a constructor-destructor pair, Approach A is
generally
more efficient. This is
especially
the case as
n
gets large. Otherwise, Approach B is probably better. Furthermore, Approach A makes the
name
w
visible in a larger scope (the one containing the loop) than Approach B, something that's contrary to program comprehensibility and maintainability. As a result, unless you know that (1) assignment is less expensive than a constructor-destructor pair and (2) you're dealing with a performance-sensitive part of your code, you should default to using Approach B.
Things to Remember
|