Effective c++学习笔记四

4 设计与声明

　　所谓软件设计，是“令软件做出你希望它做的事情”的步骤和做法，通常以颇为一般性的构想开始，最终变成十足的细节，以允许特殊接口的开发。
　　

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

　　理想上，如果客户企图使用某个接口而却没有获得他所预期的行为，这个代码不该通过编译；如果代码通过了编译，它的作为就该是客户所想要的。
　　欲开发一个“容易被正确使用，不容易被误用”的接口，首先必须考虑客户可能做出什么样的错误。
　　许多客户端错误可以因为导入新类型而获得预防。在防范“不值得拥有的代码”上，类型系统是你的主要同盟国。举例说明：
　不良代码：
　　class Date{
public：
Date(int month,int day,int year);
};
上面代码会导致调用时一错误次序传递参数。
优良代码：
struct Day
{
explicit Day(int d) //explicit 避免隐式的转换。
:val(d) { }
int val;
};
　　对日期进行类似的类型封装，能有效地避免不恰当的日期赋值。
　“除非有好的理由，否则应该尽量令你的类型（定义的类）的行为与内置类型一致”。
　　任何接口如果要求客户记得做某些事情，就是”不正确使用”的倾向。因为客户可能会忘记做那件事。在资源管理方面，也许我们应该“先发制人”，即让函数返回一个资源的指针改为返回一个智能指针。
例如：
std::tr1::shared_ptr createInvestment();
这便实质上强迫客户将返回值存储于一个tr1::shared_ptr内，几乎消除了忘记删除底部Investment对象的可能性。
　　tr1::shared_ptr提供的某个构造函数接受两个实参：一个是被管理的指针，另一个是引用次数变成0时被调用的“删除器”。但我们自己制定第二个参数，当然这是安全的。但是留给客户，那也许存在危险。

     std::tr1::shared_ptr<Investment>         //tr1::shared_ptr构造函数坚持第一个参数必须是个指针。     pInv(static_cast<Investment*>(0), getRidOfInvestment); 

　　tr1::shared_ptr有一个特别好的性质是：它会自动使用它的“每个指针专属的删除器”，因而消除另一个潜在的客户错误：所谓的“cross-DLL problem”。因为它缺省的删除器是来自“tr1::shared_ptr诞生所在的那个DLL”的delete。
　　
请记住：

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

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

　　C++就像在其它面向对象编程语言一样，当你定义一个新class，也就定义了一个新type。这意味着你并不只是类的设计者，更是类型的设计者。重载函数和操作符、控制内存的分配和归还、定义对象的初始化和终结……全部在你手上。因此你应该带着和”语言设计者当初设计语言内置类型时“一样的谨慎来研讨class的设计。
设计优秀的类是一项艰巨的工作，因为涉及好的类型是一项艰巨的工作。好的类型有自然的语法，直观的语义，以及一或多个高效实现品。
设计一个良好的类，或者称作类型，考虑一下设计规范：

新类型的对象应该如何被创建和销毁？（构造，析构，内存分配，释放函数）
对象的初始化和对象的赋值该有什么样的差别？（）
新类型的对象如果被passed by value（值传递），意味着什么？
什么是新类型的“合法值”？
你的新类型需要配合某个继承图系吗？(父类函数是不是虚函数)
你的新类型需要什么样的转换？（显示转换还是隐式转换）
什么样的操作符和函数对此新类型而言是合理的？
什么样的标准函数应该驳回？（条款6）
谁该取用新类型的成员？（public,private，friend class）
什么是新类型的“未声明接口”？(条款29)
你的新类型有多少一般化？(cass template)

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

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

　　缺省情况下C++以by value方式传递对象至函数。除非你另外指定，否则函数参数都是以实际实参的副本为初值，而调用端所获得的亦是返回值的一个副本。这些副本由对象的拷贝构造函数产生。
　　所以在以对象为by value时，可能会调用相应的构造函数（成员对象的构造、基类对象的构造），然后调用对应的析构函数。所以以by value的时间开销还是比较大的。解决办法：
如果我们用pass-by-reference-to-const，例如：
bool validateStudent(const Student& s); //const，希望别对传入对象进行不恰当的修改；
　　 这种传递方式效率高得多：没有任何构造函数或析构函数被调用，因为没有任何新对象被创建。
　　以传引用方式传递参数也可以避免slicing对象切割问题：即当一个派生类对象以传值的方式传递并被视为一个基类对象，基类对象的拷贝构造函数会被调用，而“造成此对象的行为像个派生类对象”的那些特化性质全被切割掉了，仅仅留下了基类对象。这一般不是你想要的。
　　所以我们一般的做法应该是这样：内置类型和STL的迭代器和函数对象，我们一般以传值的方式传递，而其它的任何东西都以传引用的方式传递。
　　
请记住：
尽量以pass-by-reference-to-const替代pass-by-value。前者通常比较高效，并可避免切割问题。
以上规则并不使用于内置类型，以及STL的迭代器和函数对象。对它们而言，pass-by-value往往比较适当。

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

　　当我们领悟条款20中传值的开销后，总是避免于少用传值，然而在返回对象时，要格外小心了，因为你可能：传递一些引用或指针指向其实已经不存在的对象。这可不是件好事。
　　任何时候看到一个reference声明式，你都应该立刻问自己，它的另一个名称是什么？因为他一定是某物的另一个名称。
函数创建新对象的途径有二：在栈空间和堆空间
　　栈上：即在函数内的局部对象。局部对象在函数返回后就没有存在的意义。所以传引用在栈上不可行。请注意：任何函数如果返回一个reference指向某个local 对象，都将一败涂地。下面稍作解释
　　局部对象是在被定义时创建，创建空间是栈结构，在离开生命空间时被销毁的。所谓生命空间，是指它们所在的函数体。当函数返回时，程序的控制离开了这个空间，所以函数内部所有的局部对象被自动销毁。因此，如果返回局部对象的引用，那个局部对象其实已经在函数调用者使用它之前被销毁了。
　　

Complex& Complex::operator+(Complex &c2){...}Complex& p=comp1.operator+(comp2);  //用对象的引用 接收函数返回的引用 会出错误。而返回值类型：编译器会将函数栈中的返回值数据拷贝到返回栈中即main()栈中。

　　堆上：在堆上构造一个对象，并返回。heap-based对象由new创建。看似可行，也埋下了资源泄漏的危险。谁该对这对象实施delete呢？所以传引用在堆上不可行。
　　可能还有一种想法：把“让返回的引用指向一个被定义于函数内部的静态对象”。出于我们对多线程安全性的疑虑，以及当线程中两个函数对单份对象的处理也可能带来不可测行为。所以静态对象也是不可行的。
　　 一个“必须返回新对象”的函数的正确写法是：就让那个函数返回一个新对象。
　　编程语言允许编译器实现者实行最优化，用以改善产出码的效率却不改变其观察的行为。所以我们还是老老实实的返回一个对象吧。
　　
请记住：

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

条款22：将成员变量声明为private

　　将成员变量隐藏在函数接口的背后，可以为“所有可能的实现”提供弹性。例如,这可使得成员变量被读或写时轻松通知其它对象、可以验证class的约束条件以及函数的前提和事后状态、可以在多线程环境中执行同步控制……
　　protected成员变量的封装性并不比public成员变量高。
　　某些东西的封装性与”成员变量的内容改变时所造成的的代码破坏量“成反比。所谓改变也许是从class中移除它。不封装意味不可改变！
　　
请记住：
　　切记将成员变量声明为private。这可赋予客户访问数据的一致性、可细微划分访问控制、允许约束条件获得保护，并提供class作者以充分的实现弹性。
　　protected并不比public更具封装性。
　　

条款23：宁以non-member、non-friend替换member函数

　　面向对象守则要求数据应该尽可能被封装。
　　能够访问private成员变量的函数只有class的 member函数加上friend函数。
一般我们相当然以为类中的成员函数更具封装性，而实际上并不是那么一回事，因为成员函数不仅可以访问类内的private成员变量，也可以取用private函数、enums、typedefs等等。而非成员非友元函数能实现更大的封装性，因为它只能访问public函数。
　　namespace和classes不同，前者可跨越多个源码文件而后者不能。c++标准程序库的组织方式是有数个头文件，每个头文件声明std的某些机能。
　　将所有便利函数放在多个头文件内但隶属同一个命名空间，意味客户可以轻松扩展这一组便利函数。需要做的就是添加更多non-member non-friend函数到此命名空间内。
请记住：

宁可拿non-member non-friend函数替代member函数。这样做可以增加封装性、包裹弹性和机能扩充性。

条款24：若所有参数皆需类型转换，请为此采用non-member函数

　　通常，令类支持隐式类型转换通常是个糟糕的主意。当然这条规则有其例外，最常见的例外是在建立数值类型时。
　　例：
　　

class Rational{       public:                Rrational (int numerator = 0;                           int denominator = 1);                int numerator() const;       //分子                int denominator() const;     //分母}；const Rational operator*(const Rational& rhs) const; 

如果定义一个有理数类，并实现*操作符为成员函数，如上所示；那么考虑一下调用：
Rational oneHalf(1, 2);
result = oneHalf * 2;
// 正确，因为构造函数不是explicit 类型，所以2被隐式转换
//编译器眼中应该是这样：const Rational temp(2); result = oneHalf * temp;
result = 2 * oneHalf; // 错误，2，可不被认为是Rational对象；在non-explicit 构造函数情况下，隐式转换的条件是：因为只有当参数被列于参数列内，这个参数才是隐式类型转换的合格参与者。 因此无法调用operator*。
可见，这样并不正常，因为乘法（*）应该满足交换律，不是吗？
所以，支持混合式算术运算的可行之道应该是：让operator*成为一个non-member函数，允许编译器在每一个实参上执行隐式类型转换：
class Rational
{
… // contains no operator*
};
const Rational operator*(const Rational& lhs, Rational& rhs)
{
return Rational(lhs.numerator() * rhs.numerator(),
lhs.denominator() * rhs.denominator());
}
Rational oneFourth(1, 4);
Rational result;
result = oneFourth * 2;
result = 2 * oneFourth; //这下两个都工作的很好，通过隐式转换实现
　　成员函数的反面是非成员函数，而不是友元函数。
　　无论何时如果可以避免friend函数就该避免。
　　本条款只适用于Object-Oriented c++(条款1)
请记住：
　　如果你需要为某个函数的所有参数（包括被this指针所指的那个隐喻参数）进行类型转换，那么这个函数必须是个non-member。

条款25：考虑写出一个不抛异常的swap函数

　　swap函数原本只是STL的一部分 ，而后成为异常安全性编程的脊柱。以及用来处理自我赋值可能性的一个常见机制。当swap的缺省代码的实现效率不足时，可以为标准templat制造特化版本，使它专属于我们自己的classes
如果swap的缺省实现码对你的class提供的效率不足，则试着做以下事情：
1.提供一个public swap成员函数，让它高效的置换你的类型的两个对象值，
2.在你的class或template所在的命名空间提供一个non-member swap ,并令它调用上述swap成员函数
3.如果你在编写一个类，为你的class特化 std::swap。并令他调用你的swap函数
最后包含一个using 声明式，以便让std::swap在你的函数内曝光可见。
请记住：
　　当std::swap对你的类型效率不高时，提供一个swap成员函数，并确定这个函数不抛出异常。
　　如果你提供一个member swap，也该提供一个non-member swap用来调用前者。对于class（而非templates），也请特化std::swap。
　　调用swap时应针对std::swap使用using声明式，然后调用swap并且不带任何“命名空间资格修饰”。
　　为“用户定义类型”进行std templates全特化是好的，但千万不要尝试在std内加入某些对std而言全新的东西。