Effective C++ 笔记

进度: 条款35

2009.6.21:

条款13: 初始化列表中成员列出的顺序和它们在类中声明的顺序相同
 这个条款让我觉得比较不爽，因为这样的话，在对类的数据成员进行声明时必须要小心翼翼，当一个项目中充满了很多类

时，不能保证不出现奇怪的
问题。这个是初始化列表的一个比较显著的缺陷了。对于初始化列表，这个算是一个唯一的缺陷了吧，因为它并没有给程序员足够

的自由，
而是对程序员的自由进行了限制，而且这个限制多少有点隐晦。
 但是即便如此，初始化列表还是远远利大于弊，因此作为C++程序员我必须要遵守语言的游戏规则，那么这个记住就好，在

设计类的数据成员时，’
一定要对其相互依赖关系进行手工排序。

条款16: 在operator=中对所有数据成员赋值
 这个条款重点指明了在赋值和拷贝构造函数里，对基类成员的处理。不难看出，当派生类的赋值函数和拷贝构造函数被调

用时，其基类的对应
函数并没有被调用！这将导致在派生类中，基类的那部分成员的数值是不确定的(至少不是被拷贝的那个对象的数值)。解决这个问

题的一个方案就是
手工调用基类的复制和拷贝构造函数，这样才能保证所有的成员都被正常的初始化了。在这里要明确记住的是，派生类的赋值和拷

贝构造函数不会自动
的调用基类的对应函数，必须要手工调用才可以保证派生类成员被顺利的正常初始化。

条款17: 在operator=中检查给自己赋值的情况
 这个条款很有意思，我过去也很少考虑这个问题，这再次说明了人不能自我感觉过于良好，否则就没法前进了呵呵。自我

赋值在比较好的情况下只会
导致一些调用开销，但在差的情况下就会导致程序崩溃掉。就像书中提到的那样，当=运算是要先释放掉旧资源，再申请新资源时，

这个问题就非常明显了。
另外有关两个对象在什么条件下才是一致的，这也是面向对象领域的一个名论题了，不那么学术的去考虑，在大多数情况下，连个

内存地址完全相同的对象，
我就认为他们是相等的了，这点应该算是从物理层面上来定义对象相同的问题，当然程序员通过重载=运算符，也可以在更高的逻辑

层面上定义出对象相等
的判别条件来，总之无论是哪个层面，这个定义必须有，判断必须做，否则可能导致潜藏很深的BUG。

条款27:  如果不想使用隐式生成的函数就要显式地禁止它
 这里还是使用了拷贝构造函数和赋值构造函数为例子，我觉得有意思的是实现的方法，使用一个定义但不实现的
的方法，这样一来，只要你不调用这个函数，那么编译器也不回说有什么不妥当的的地方，但是一旦你调用了这个函数，
那么编译器(更确切的说是链接器)就会给你一个不小的惊喜，这个方法非常好，利用了编译器的规则达到了目的

条款29: 避免返回内部数据的句柄
 这个条款指明了类的方法不能做的一件事。就是返回类内部数据成员的句柄或者是能够修改的直接引用(包含指针)。因为
 被返回出来的句柄很可能有由于调用者的无知而造成类内数据成员的无意识被修改，其次更有可能由于对象生存周期的
 问题，导致出现悬空指针或者悬空引用。那将会是非常危险的，而且比较难于Debug。

条款34: 将文件间的编译依赖性降至最低
 这一条非常重要。。。我曾经对这个问题非常的纠结，导致项目没法编译，呵呵。现在看来，在头文件中使用类前置
 声明，而在实现的cpp文件里再包含该类的头文件的做法是非常正确的。唯一的缺点就是在头文件里要写一些前置的
 类声明语句，但是和它到来的将编译依赖性降低的好处来说，这点缺点确实不值得一提.