C++箴言：只要有可能就推迟变量定义

在很大程度上，为您的类(包括类模板)和函数(包括函数模板)提供正确的定义是战斗的关键部分。一旦得到正确的结果，相应的实现就非常简单了。但是还是要做一些防范。过早定义变量会拖累性能。过度的强制转换将导致缓慢、难以维护的代码，并被细微的错误所困扰。返回一个类内部组件的句柄会破包，把空挂句柄留给客户。忽视考虑异常的影响会导致资源的泄漏和数据结构的破坏。过度的内联会导致代码膨胀。过度耦合将导致不可接受的长施工时间。这些问题都是可以避免的。

尽可能延迟变量定义。

只要用构造函数和析构函数定义一个变量，当控制流到达变量定义时，你就承担了构造成本，当变量离开作用域时，你就承担了分析成本。如果存在造成这种成本的无用变量，就要尽量避免。

你可能认为你永远不会定义无用的变量，但也许你应该再想想。考虑下面的函数，只要密码长度符合要求，它就返回密码的加密版本。如果密码太短，该函数将抛出标准C++库中定义的logic_error类型的异常(参见第54项):

//此函数定义变量“encrypted”过早
STD::string encrypt password(const STD::string & password)
{
使用命名空间STD；

字符串加密；

if(Password . length()< MinimumPasswordLength){
throw logic _ error("密码太短")；
}
...//执行任何必要的操作，将
//加密版本的密码放入加密的
返回加密的；
}

加密的对象在这个函数中不是完全没用，但是如果抛出异常就没用了。换句话说，即使encryptPassword抛出异常，也要为构造和析构encrypted付出代价。因此，得出了以下结论:你推迟了加密的定义，直到你确信你真的需要它:

//该函数将encrypted的定义推迟到真正需要时
STD::string encrypt password(const STD::string & password)
{
使用命名空间STD；

if(Password . length()< MinimumPasswordLength){
throw logic _ error("密码太短")；
}

字符串加密；

...//执行任何必要的操作，将
//加密版本的密码放入加密的
返回加密的；
}

这段代码仍然不够紧凑，因为encrypted是在没有任何初始化参数的情况下定义的。这意味着在许多情况下，将使用它的默认构造。你应该为一个对象做的第一件事是给它一些值，这通常可以通过赋值来完成。我已经解释了为什么默认构造一个对象然后给它赋值比用你真正需要它保存的值初始化它效率更低。这一分析也适用于此。例如，假设encryptPassword的核心部分是在这个函数中完成的:

void encrypt(STD::string & s)；//就地加密s