条款26：尽可能延后变量定义式的出现时间

1.前言

只要定义了一个变量而该变量的类型带有一个构造函数或析构函数，那么当程序的控制流到达这个变量定义式时，你便得承受构造成本；当这个变量离开其作用域时，你便得承受析构成本。即使这个变量最终并未被使用，仍需耗费这些成本，所以应该尽可能避免这种情形。

2.实例分析

或许我们会认为，我们不可能定义一个不使用的变量，但话不要说的太早。以下面这个函数为例，它计算通行密码的加密版本而后返回，前提是密码足够iou长。如果密码太短，函数会丢出一个异常，类型为logic_error：
 

std::string encryptPassword(const std::string& password)
{

    using namespace std;
    string encrypted;
    if(password.length()<MinimumPasswordLength){
        throw logic_error("Password is too short");
    }
    .....//必要的动作，能产生一个加密后的密码，置入变量entrypted内
    return encrypted;  
}

对象encrypted在此函数中并非完全被使用，但如果有个异常被丢出，它就真的没被使用。也就是说如果函数encryptPassword丢出异常，你仍得付出encrypted的构造成本和析构成本。所以最好延后encrypted的定义式，直到确实需要它：

std::string encryptPassword(const std::string& password){

    using namespace std;
    if(password.length()<MinimumPasswordLength){
        throw logic_error("Password is too short");
    }
    string encrypted;
    ...//必要的动作，产生一个加密后的密码，置入变量encrypted内
    return encrypted;
}

但这段代码依然不够完美，因为encrypted虽获定义却无任何实参作为初值。这意味着调用的是其default构造函数，许多时候对该对象做的第一件事情就是给它个初值，通常是通过一个赋值动作达成。举个例子，假设encryptPassword的艰难部分在以下函数中进行：

void encrypt(std::string& s);//在其中适当的地点对s进行加密

于是encryptPassword可实现如下，虽然还不算是最好的做法：

//这个函数延后“encrypted”的定义，直到需要它为止。
//但此函数仍然有着不该有的效率低的特点
std::string encryptPassword(const std::string& password){

    ...//检查length
        //default construct encrypted
        //赋值给encrypted
    encrypt(encrypted);
    return encrypted;  
}

更受欢迎的做法是以password作为encrypted的初值，跳过毫无意义的default构造过程。

//终于，这是定义并初始化encrypted的最佳做法
std::string encryptPassword(const std::string& password){

    ...//检查长度
    std::string encrypted(password);//通过copy构造函数
    encrypt(encrypted);
    return encrypted;
}

这让我们联想起本条款所谓的“尽可能延后”的真正意义。你不只应该延后变量的定义，直到非的使用该变量的前一刻为止，甚至应该尝试延后这份定义直到能够给它初值实参为止。如果这样，不仅能够避免构造非必要的对象，还可以避免无意义的default构造行为。更深一层说，以“具明显意义的初值”将变量初始化，还可以附带说明变量的目地。

”但循环怎么办“，你可能会疑惑。如果变量只是在循环内使用，那么把它定义于循环外并在每次循环迭代时赋值给它比较好，还是该把它定义于循环内比较好？也就是说下面左右两个一般性结构，哪个比较好？

//方法A：定义于循环外
Widget w;
for(int i=0;i<n;++i){
    //取决于i的某个值
    ...
}
//方法B：定义于循环内
for(int i=0;i<n;++i){

    Widget w;(取决于i的某个值)
    ...
}

在这里，我把对象的类型从string改为Widget，以免造成读者对于“对象执行构造/析构/或赋值动作所需的成本”有任何特殊的偏见。

在Widget函数的内部，以上两种写法的成本如下：

做法A：1个构造函数+1个析构函数+n个赋值操作

做法B：n个构造函数+n个析构函数

如果classes的一个赋值成本低于一组构造+析构成本，做法A大体而言比较高效。尤其是n值很大的时候。否则做法B比较好。此外做法A造成名称w的作用域比做法B更大，有时候会对程序的可理解性和易维护性造成冲突。因此除非（1）你知道赋值成本比“构造+析构”成本低；（2）你正在处理代码中效率高度敏感的那部分。否则应该使用做法B