《Effective C++》学习笔记(5)

4 设计与声明

条款18：让接口容易被正确使用，不易被误用

理想上，如果客户企图使用某个接口而却没有获得他所预期的行为，这个代码不该通过编译；如果代码通过了编译，它的作为就该是客户所想要的。欲开发一个“容易被正确使用，不容易被误用”的接口，首先必须考虑客户可能做出什么样的错误。

• 许多客户端错误可以因为导入新类型而获得预防。在防范“不值得拥有的代码”上，类型系统是你的主要同盟国。

struct Day     {         
explicit Day(int d)        //explicit 避免隐式的转换。
    :val(d) {}        
int val;      
};  
... ...
class Date  {
public:
    Date(const Month& m, const Day& d, const Year& y);
... ...
}   
// 使用
Date d(Month(3), Day(30), Year(1995));

对日期进行类似的类型封装，能有效地避免不恰当的日期赋值。
对值的限制可通过枚举方法实现。

• “除非有好的理由，否则应该尽量令你的类型（定义的类）的行为与内置类型一致”。

• 在资源管理方面，让函数返回一个资源的指针改为返回一个智能指针，以把delete责任推给智能指针。
  例如：

std::tr1::shared_ptr<Investment> createInvestment();    

这便实质上强迫客户将返回值存储于一个tr1::shared_ptr内，几乎消除了忘记删除底部Investment对象的可能性。

• tr1::shared_ptr有一个特别好的性质是：它会自动使用它的“每个指针专属的删除器”，因而消除另一个潜在的客户错误：所谓的“cross-DLL problem”。这个问题发生于“对象在动态链接程序库（DLL）中被new创建，却在另一个DLL内被delete销毁”。tr1::shared_ptr没有这个问题，因为它缺省的删除器是来自“tr1::shared_ptr诞生所在的那个DLL”的delete。

note：

1. 好的接口很容易被正确使用，不容易被误用。你应该在你的所有接口中努力达成这些性质。
2. “促进正确使用”的办法包括接口的一致性，以及与内置类型的行为兼容。
3. “阻止误用”的办法包括建立新类型、限制类型上的操作，束缚对象值，以及消除客户的资源管理责任。
4. tr1::shared_ptr支持定制删除器。这可防范DLL问题，可被用来自动解除互斥锁（条款14）等等。

---

条款19：设计 class 犹如设计 type

C++就像在其它面向对象编程语言一样，当你定义一个新class，也就定义了一个新type。这意味着你并不只是类的设计者，更是类型的设计者。重载函数和操作符、控制内存的分配和归还、定义对象的初始化和终结......全部在你手上。

设计一个良好的类，或者称作类型，需要考虑以下设计规范：

• 新类型的对象应该如何被创建和销毁？
• 对象的初始化和对象的赋值该有什么样的差别？
• 新类型的对象如果被passed by value（值传递），意味着什么？
• 什么是新类型的“合法值”？
• 你的新类型需要配合某个继承图系吗？
• 你的新类型需要什么样的转换？
• 什么样的操作符和函数对此新类型而言是合理的？
• 什么样的标准函数应该驳回？
• 谁该取用新类型的成员？
• 什么是新类型的“未声明接口”？
• 你的新类型有多少一般化？
• 你真的需要一个新类型吗？

note：
class的设计就是type的设计。在定义一个新type之前，请确定你已经考虑过本条款覆盖的所有讨论主题。

---

条款20：宁以 pass-by-reference-to-const 替换 pass-by-value

缺省情况下C++以by value方式传递对象至（或来自）函数。除非你另外指定，否则函数参数都是以实际实参的副本为初值，而调用端所获得的亦是返回值的一个副本。

这些副本由对象的拷贝构造函数产生。所以在以对象为pass by value时，可能会调用相应的构造函数（成员对象的构造、基类对象的构造），然后调用对应的析构函数。所以以by value的形式传递开销还是比较大的。

如果我们用pass-by-reference-to-const，例如：

bool validateStudent(const Student& s);     //const，希望别对传入对象进行不恰当的修改；     

这种传递方式效率高得多：没有任何构造函数或析构函数被调用，因为没有任何新对象被创建。

以传引用方式传递参数也可以避免对象切割问题：即当一个派生类对象以传值的方式传递并被视为一个基类对象，基类对象的拷贝构造函数会被调用，而“造成此对象的行为像个派生类对象”的那些特化性质全被切割掉了，仅仅留下了基类对象。这一般不是你想要的。解决切割问题的办法，就是以by-reference-to-const的方式传递。

所以我们一般的做法应该是这样：内置对象和STL的迭代器和函数对象，我们一般以传值的方式传递，而其它的任何东西都以传引用的方式传递。

note：

1. 尽量以pass-by-reference-to-const替代pass-by-value。前者通常比较高效，并可避免切割问题。
2. 以上规则并不适用于内置类型，以及STL的迭代器和函数对象。对它们而言，pass-by-value往往比较适当。

---

条款21：必须返回对象时，别妄想返回其reference

当我们领悟条款20中传值的开销后，总是避免于少用传值，然而在返回对象时，要格外小心了，因为你可能：传递一些引用或指针指向其实已经不存在的对象。这可不是件好事。

任何时候看到一个reference声明式，你都应该立刻问自己，它的另一个名称是什么？

函数创建新对象的途径有二：在栈空间和堆空间

• 栈（stack）上：即在函数内的局部变量。局部变量在函数返回后就没有存在的意义，若还对它“念念不忘”，将带来灾难性后果。所以传引用在栈上不可行。

• 堆（heap）上：在堆上构造一个对象，并返回。看似可行，也埋下了资源泄漏的危险。谁该对这对象实施delete呢？别把这种对资源的管理寄托完全寄托于用户。所以传引用在堆上不可行。

• 可能还有一种想法：把“让返回的引用指向一个被定义于函数内部的静态对象”。出于我们对多线程安全性的疑虑，以及当线程中两个函数对单份对象的处理也可能带来不可测行为。所以静态对象也是不可行的。

一个“必须返回新对象”的函数的正确写法是：就让那个函数返回一个新对象。

编译器实现者实行最优化，用以改善产出码的效率却不改变其观察的行为。所以我们还是老老实实的返回一个对象吧。

note：
绝不要返回pointer或reference指向一个local stack对象，或返回reference指向一个heap-allocated对象，或返回pointer或reference指向一个local static对象而有可能同时需要多个这样的对象。