目录
条款20:宁以pass-by-reference-to-const替代pass-by-value
条款23:宁以non-member、non-friend替换member函数
条款24:若所有参数皆需类型转换,请为此采用non-member函数
条款18:让接口容易被正常使用,不易被误用
好的接口很容易被正确使用,不容易被误用。你应该在你的所有接口中努力达成这些性质
“促进正确使用”的办法包括接口的一致性,以及与内置类型的行为兼容
“阻止误用”的办法包括建立新类型、限制类型上的操作,束缚对象值,以及消除客户的资源管理责任
tr1::shared_ptr支持定制型删除器,这一特性可以用于防范DLL问题(不同的库文件中的new和delete使用可能会引发错误),也可被用来自动拆除互斥锁(上锁后需要解锁)等等。
条款19:设计class犹如设计type
为了设计出高效的的class,应该满足下列设计规范:
新types的对象应该如何被创建和销毁(涉及构造析构内存分配和释放)
对象的初始化和对象的赋值该有什么差别
新type的对象如果被passed by value(值传递),意味着什么
什么是新type的“合法值”(类成员的约束条件)
你的新type需要配合某个继承图系(虚继承,函数重写,析构函数是否为虚函数等问题)
你的新type需要什么样的转换(一般要求构造函数是explicit的,根据实际情况判断是否需要隐式类型转换或显式类型转换)
什么样的操作符和函数对此新type而言是合理的
什么样的标准函数应该驳回(哪些函数应设为private)
谁该取用新type的成员(哪个成员为public,哪个为protected,哪个为private,哪个类和函数为友元)
什么是新type的“未声明接口”
你的新type有多一般化?(是设计一个class,一个class族还是模板)
你真的需要一个新的type吗(是否能用非成员函数或template实现)
条款20:宁以pass-by-reference-to-const替代pass-by-value
不同于内置类型,自定义的类(string等类也要)都要经历构造和析构的过程,如果是继承的派生类就要经历更多的构造和析构,因此当我们使用自定义类时尽量以引用传递代替值传递(即使类只包含一个内置类型),以上规则并不适合内置类型以及STL的迭代器和函数对象,对他们而言值传递更合适
并且值传递无法引发多态,引用传递则可以
条款21:必须返回对象时,别妄想返回其引用
绝对不要返回pointer或reference指向一个local stack对象,或返回reference指向一个heap-allocated对象,或返回pointer或reference指向一个local static对象而有可能同时需要多个这样的对象(多次对同一个static操作)
条款22:将成员变量声明为private(所有成员)
切记将成员变量声明为private。这可以赋予访问数据的一致性(访问所有的内容都是通过函数接口而不是直接访问内容)、可细微划分访问控制(将访问内容细微划分为只读,只写,读写和无任何访问动作)、允许约束条件获得保证,并提供class作者充分的弹性实现(通过函数隐藏实现)
protected并不比public更具备封装性(有继承时更明显)
条款23:宁以non-member、non-friend替换member函数
宁可拿non-member non-friend函数替换member函数(可以通过非成员和非友元函数调用接口实现)。这样做可以增加封装性、包裹弹性和机能扩充性
条款24:若所有参数皆需类型转换,请为此采用non-member函数
当所有参数都需要类型转换(比如运算符两端的参数都需要类型转换时),如果以成员函数的形式进行那只有一边的参数可以默认的类型转换,因此必须时个non-member函数
条款25:考虑写出一个不抛出异常的swap函数
当std::swap对你的类型效率不高时(与指针有关),提供一个swap成员函数,并确定这个函数不抛出异常(对内置类型操作几乎不会抛出异常)
如果你提供一个member swap,也该提供一个non-member swap用来调用前者(方便统一格式)。对于class(而非templates),也请特化std::swap(全特化也是调用成员函数,对模板而言则不行,自定义模板的特例化需要在其他命名空间中实现)
调用swap时应针对std::swap使用using声明式,然后调用swap并且不带任何“命名空间资格修饰”
为“用户定义类型”进行std templates全特化是好的,但千万不要尝试在std内加入某些对std而言全新的东西