Remember that when 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. This means there's a cost associated with unused variables, so you want to avoid them whenever you can.
Suave and sophisticated in the ways of programming as I know you to be,
you're probably thinking you never define unused variables, so this
Item's advice is inapplicable to your tight, lean coding style. 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 49):
// this function defines the variable "encrypted" too soon string encryptPassword(const string& password) { string encrypted; if (password.length() < MINIMUM_PASSWORD_LENGTH) { throw logic_error("Password is too short"); } do whatever is necessary to place an encrypted version of password in encrypted; return encrypted; }
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 string encryptPassword(const string& password) { if (password.length() < MINIMUM_PASSWORD_LENGTH) { throw logic_error("Password is too short"); } string encrypted; do whatever is necessary to place an encrypted version of password in encrypted; return encrypted; }
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 12 explains why
default-constructing an object and then assigning to it is a lot 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(string& s); // encrypts s in place
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 string encryptPassword(const string& password) { ... // check length as above string encrypted; // default-construct encrypted encrypted = password; // assign to encrypted encrypt(encrypted); return encrypted; }
encrypted
with
password
, thus skipping the (pointless) default construction:
// finally, the best way to define and initialize encrypted string encryptPassword(const string& password) { ... // check length string encrypted(password); // define and initialize // via copy constructor encrypt(encrypted); return encrypted; }
By postponing variable definitions, you improve program efficiency, increase program clarity, and reduce the need to document variable meanings. It looks like it's time to kiss those block-opening variable definitions good-bye.