[译]GotW #1: Variable Initialization

原文地址：http://herbsutter.com/2013/05/09/gotw-1-solution/

第一个问题强调的是要明白自己在写什么的重要性。下面有几行简单的代码--它们大多数之间都有区别，尽管在语法上只有轻微的不一样。

Problem

JG Question

1. 下面代码存在差异吗？

widget w;            // ( a )

widget w();           // ( b )
widget w{};           // ( c )

widget w( x );        // ( d )
widget w{ x };        // ( e )

widget w = x;            // ( f )
widget w = { x };        // ( g )

auto w = x;               // ( h )
auto w = widget { x };    // ( i )

Guru Questions

2. 下面每行代码都做了什么？

vevtor<int> v1 (, );    // ( a )
vector<int> v2 { , };   // ( b )

3. 除了上面代码，使用{}初始化对象还有什么其他好处？

4. 在什么时候应该使用（）或者{ }语法来初始化对象？为什么？

Solution

上面的代码说明了一下几件事情：

　　· 默认初始化、直接初始化、拷贝初始化和列表初始化之间的区别。

　　· 使用（）和{ }初始化的区别。

　　· A red herring that isn’t initialization at all( 译注：※)，现代C++应彻底避免。

最重要的是：如果坚持在#4节介绍的两个原则，就可以忽略上面的大多数情况，规则很简单，却可以在默认的情况下提供高效的性能。

Answer 1.

（a）是默认初始化

widget w;        // ( a )

上面代码声明了一个类型为widget，名字叫w的变量，对于大多数类型，它们是使用默认的构造函数widget::widget()来初始化的。

要注意的是，如果widget是内建类型，比如int或者一些类似int（int-like）的

　　1.依赖编译器为它们产生默认的构造函数，

　　2.且没有虚函数或者

　　3.虚基类或者

　　4数据成员初始化函数

的类型或者满足类似满足上述条件的类型，那么w是没有被初始化的，且包含了一些“垃圾”值。

（b）是令人烦恼的red herring（转移注意力的话题），现在主要属于一个历史性的玩意。

widget w();    // ( b )

这是一个前-现代C++的陷阱：大致一看，它好像是一个使用默认构造函数widget::widget()的变量声明语句，但是这里存在一个个语法的二义性。它可以是一个名字为w的，不带参的，返回值为widget的（传值）的函数声明。

免得可以能会认为：“这里的圆括号（）是多余的，这是程序员自己犯的错，他可以写成widget w;这样”。但是要注意的是存在着一个偶然的情况下会引起同样的问题，比如可能会用临时变量来初始化：

// same problem ( gadget and dooead are types )

widget w( gadget( ), doodad( ) );    // pitfall: not a variable declaration

Scott Meyers老早前就把它命名为“C++’s most vexing parse（C++最棘手的解析）”。因为C++标准在面对这样的二义性时，是以“如果它可以是一个函数声明，那么它就是函数声明”为标准的。

好消息是，这只是属于历史的一个玩意，在现代C++代码中应该是不会遇到的，因为C++11移除了这陷阱。注意C++11并没有改变代码的意思，C++11对C++98有着很强的向后兼容性，同样包括这样的二义性。C++11是通过提供一个语法，几乎在所有情况下来取代（b）这种情况，因此没必要再次掉入这样的陷阱当中了，如：

（c）是非棘手且明确的

widget w{ };    // ( c )

我们有了第一个优先选择{}的理由：对于任意类型widget，上面代码做了（a）和（b）应该做的事--总是初始化变量，且它不会存在函数声明的二义性。没有烦恼，没有混乱。

“啊，等等，没有它看上去那么简单！”有人可能会反对。“假如widget有一个带std::initializer_list参数的构造函数怎么办？因此如果有的话，就不能这样调用的吧？”

答案是否定的，它就是看上去那么简单。因为标准明确：一个空的{}列表意味着调用默认的构造函数，如果有的话。但是，应该注意有std::initializer_list这样的情况，接着看下一个。

（d）和（e）都是直接初始化

现在考虑从已存在的变量来初始化w的情况：

widget w(x);                // (d)
widget w{x};                // (e)

假设x不是一个类型名，上面两个都是直接初始化。因为变量w通过调用widget::widget(x)“直接”从x的值来初始化。如果x也是widget类型，那么会调用拷贝构造函数，否则，调用一个转换构造函数。然而要注意，{x}语法创建了一个initializer_list，如果widget有一个带initializer_list参数的构造函数，那么这个构造函数会被优先选择。否则，如果widget有一个带任意类型x的构造函数，那么此构造函数则会被调用。
相对于（d）优先选择（e）有两个主要的区别：

第一，像（c）一样，（e）是一个没有二义性且避免了棘手的解析。如果x是一个类型名，那么（d）就是一个函数声明语句，即使在作用域范围内存在一个同名的x变量，而（e）绝不可能是个函数声明语句。

第二，（e）更安全，因为它不允许值变窄（narrowing，又名“lossy”）转换，不允许一些内置的类型，比如：

int i1( 12.345 );           // ok: toss .345, we didn't like it anyway
int i2{ 12.345 };           // error: would be lossy implicit narrowing

（f）和（g）是拷贝初始化和拷贝列表初始化
这是最后两个非auto的情况：

widget w = x;               // (f)

这称为“拷贝初始化”，从概念上来说，变量w使用widget的移动或拷贝构造函数来初始化，可能在隐式地调用其它函数来转换这个参数之后。（这里不会调用explicit转换）

Common Mistake：这总是初始化，它绝不会是赋值，因此绝不会调用T::operator=()。我知道那里有个“=”字符，but don’t let that throw you。那只是一个C的延续语法，不是赋值操作。

下面是它们的语义：
　　· 如果x是widget类型，（f）和（d）widget w(x)的意义是相同的，除了explicit构造函数不能使用之外。它保证了只有一个构造函数被调用。
　　· 如果x是其他类型，从概念上来说，编译器会先隐式地将x转换成一个临时的widget对象，然后对临时右值使用移动构造函数，如果没有移动构造函数，那么使用拷贝构造函数　　  作为后备。假设可以隐式转换，那么（f)的意义和widget w( widget(x) );是相同的。

注意到上面说了几次“从概念上”，那是因为实际中编译器允许，且经常地优化掉临时对象，如果可以隐式转换，从（f）到（d），因此优化掉多余的移动操作。然而，即使当编译器这么做，widget的拷贝构造函数任然必须是可访问的，即使不被调用，拷贝构造函数的副作用可能会也可能不会发生，that’s all.

现在看一下追加了“=”的相关语法：

widget w = {x};             // (g)

这个称为“拷贝列表初始化”。它的意思和widget w{x};相同。除了explicit构造函数不能使用之外。它保证了只有一个构造函数被调用。

（h）和（i）都是拷贝初始化，但更简单

auto w = x;                 // (h)
auto w = widget{x};         // (i)

语义正如（f）和（g），除了更方便教学、学习和使用。因为使用auto保证了右手端的表达式类型会被精确地推导。要注意的是语句（i）对于隐式和显示的转换都能工作。

（h）行的意思和（d）相同，type_of_x w(x);。只有一个构造函数被调用。它保证了在程序演变过程中的一致性：因为（h）行没有承诺一个显示的类型，它同时保证了效率的最大化（因为没有涉及转换）和健壮性的最大化（因为w类型会“自动”地跟踪类型，如果程序在维护中改变的情况下）

当你想要确定一个指定的类型和需要显示转换，那么（i）行是最一致的使用手段。再一次，{}语法避免了有损收缩转换。实际上在多数编译器中，只有一个构造函数会被调用，和我们在（f）和（g）看到的一样。从概念上说调用了两个构造函数，一个转换或者一个拷贝构造函数创建一个临时的widget{x}，紧接着通过移动构造将它“移动”到w,但是编译器经常会省略（优化）后者。

一般来说，我建议你尝试上面两种形式的语句。随着你习惯了它们之后就会越来越喜欢使用它们。我现在倾向于使用这种方式来声明所有局部变量。（我知道你们当中有些人会怀疑这种用法，更多关于“auto的问题”在另外一篇GotW中）。