项目中的错误：成员初始化列表

从概念上讲，构造函数分为两个阶段执行：初始化阶段，计算阶段。计算阶段由构造函数体中的所有语句组成。
使用初始化式有两方面的原因，第一是必要性。有三种情况必须使用成员初始化列表。
1. 没有默认构造函数的类成员。
2. const成员
3. 引用类型成员
原因很简单，因为上面说了，初始化阶段是在构造函数体外就开始的。所以如果默认构造函数的话会无法初始化。而const和引用类型的成员，如果没有初始化列表，编译器会报错，提示你需要初始化。因此，const和引用成员唯一初始化的机会就是在初始化列表中。
第二是效率考虑。
当成员类具有一个缺省的构造函数和一个赋值操作符时。MFC的CString提供了一个完美的例子。假定你有一个类CMyClass具有一个CString类型的成员m_str，你想把它初始化为"Hi,how are you."。你有两种选择：

CMyClass::CMyClass() {
// 使用赋值操作符
// CString::operator=(LPCTSTR);
m_str = _T("Hi,how are you.");
}
// 使用初始化列表
// 和构造函数 CString::CString(LPCTSTR)
CMyClass::CMyClass() : m_str(_T("Hi,how are you."))
{

在它们之间有什么不同吗？是的。编译器总是确保所有成员对象在构造函数体执行之前被初始化，因此在第一个例子中编译的代码将调用CString::Cstring来初始化m_str，这在控制到达赋值语句前完成。在第二个例子中编译器产生一个对CString:: CString(LPCTSTR)的调用并将"Hi,how are you."传递给这个函数。结果是在第一个例子中调用了两个CString函数（构造函数和赋值操作符），而在第二个例子中只调用了一个函数。

在CString的例子里这是无所谓的，因为缺省构造函数是内联的，CString只是在需要时为字符串分配内存（即，当你实际赋值时）。但是，一般而言，重复的函数调用是浪费资源的，尤其是当构造函数和赋值操作符分配内存的时候。在一些大的类里面，你可能拥有一个构造函数和一个赋值操作符都要调用同一个负责分配大量内存空间的Init函数。在这种情况下，你必须使用初始化列表，以避免不要的分配两次内存。
在内建类型如ints或者longs或者其它没有构造函数的类型下，在初始化列表和在构造函数体内赋值这两种方法没有性能上的差别。
不管用那一种，当我考虑初始化列表的问题时，有一个奇怪的特性我应该警告你，它是关于C++初始化类成员的，它们是按照声明的顺序初始化的，而不是按照出现在初始化列表中的顺序。方法，都只会有一次赋值发生。

class CMyClass {
CMyClass(int x, int y);
int m_x;
int m_y;
};
CMyClass::CMyClass(int i) : m_y(i), m_x(m_y)
{
}

你可能以为上面的代码将会首先做m_y=i，然后做m_x=m_y，最后它们有相同的值。但是编译器先初始化m_x，然后是m_y,，因为它们是按这样的顺序声明的。结果是m_x将有一个不可预测的值。这个例子是故意这样设计来说明这一点的，然而这种bug会很自然地出现。有两种方法避免它，一个是总是按照你希望它们被初始化的顺序来声明成员，第二个是，如果你决定使用初始化列表，总是按照它们声明的顺序罗列这些成员。这将有助于消除混淆。