1) 接口中函数越多，以后的潜在用户就越难理解。
2) 接口中函数越多，越难以维护。
3) 类的定义太长会导致项目开发过程中浪费大量的编译时间。
评论：接口复杂导致编译器对.h头文件长时间解析，并占用大量内存，导致编译时间变长。简单的.h和接口，可以加速编译速度。
条款19: 分清成员函数，非成员函数和友元函数
1) 虚拟函数必定是某个类的成员函数。
2) 能避免使用友元函数就要避免。
3) 需要访问非公有成员的非成员函数只能是类的友元函数。
评论：友元函数的引入相当于对类的私有数据开放了一个后门。所以说后门无处不在啊。
条款20: 避免public接口出现数据成员
评论：C++编程中本来就是面向对象的操作，并非面向对象的数据访问。在public接口里放上数据成员无异于自找麻烦，所以要把数据成员安全地隐藏在与功能分离的高墙后。
条款21: 尽可能使用const
1) 一条垂直线穿过指针声明中的星号（*）位置:a) 如果const出现在线的左边，指针指向的数据为常量；
b) 如果const出现在线的右边，指针本身为常量；c) 如果const在线的两边都出现，二者都是常量。
2) 让函数返回一个常量值经常可以在不降低安全性和效率的情况下减少用户出错的几率。
3) bitwise constness正是c++对const问题的定义，const成员函数不被允许修改它所在对象的任何一个数据成员。
评论：尽可能的使用const，并非是说都要用，有的情况并不适合使用const返回值。这一点要记在心中。
条款22: 尽量用“传引用”而不用“传值”
1) 非常高效：没有构造函数或析构函数被调用，因为没有新的对象被创建。
2) 避免了所谓的“切割问题（slicing problem）”。
3) 如果是一个很小的对象——例如byte——传值实际上会比传引用更高效。
4) 有时不能用引用来传递对象，参见条款23。
评论：引用和传值在C语言中相对应于传址和传值。
条款23: 必须返回一个对象时不要试图返回一个引用
评论：临时变量不能作为引用返回，因为当函数返回时，临时变量会被销毁。
条款24: 在函数重载和设定参数缺省值间慎重选择
1) 确实有那么一个值可以作为缺省吗？
2) 要用到多少种算法？
评论：如果函数输入参数多个，输入参数有默认值的情况，通常不需要选择函数重载来实现，当然如果你一定要，只能增加冗余代码量，并且不便于算法的维护。
条款25: 避免对指针和数字类型重载
评论：指针和内容是两个完全不同的性质东西，对于重载函数设计接口，要避免参数是两个完全不同的东西。因为至少我们要确保入口参数性质是一样的，无非类型有差异。
条款26: 当心潜在的二义性
评论：多继承的成员的引用要显式地消除二义性
条款27: 如果不想使用隐式生成的函数就要显式地禁止它
评论：将不想使用的，但系统会自动生成的函数，显示声明到private下面，而代码不实现。可以消除类成员函数调用(编译时告警)，友元私有函数调用问题(链接时告警)。
条款28: 划分全局名字空间
评论：名字空间概念的引入主要为了更好的解决全局变量二义性的问题。
第一章：从C转向C++ （Effective C++ Second Edition 读书笔记）
第二章：内存管理(Effective C++ Second Edition 读书笔记)
第三章：构造函数，析构函数和赋值操作（Effective C++ Second Edition 读书笔记）
第四章 类和函数：设计与声明(Effective C++ Second Edition 读书笔记)
第五章 类和函数：实现(Effective C++ Second Edition 读书笔记)第六章 继承和面向对象设计 (Effective C++ Second Edition 读书笔记)
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
