Effective C++读书笔记(条款24-29)

Effective C++第四篇，扩展的有点多...

(四).设计与声明

____________________________________________________________________________________________________________________________________

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

#1.如果你需要为某个函数的所有参数（包括被 this指针所指的那个隐喻参数）进行
类型转换，那么这个函数必须是个 non-member。

//假设有个有理数类:class Rational{public:    Rational(int numrator=0, int denomination=1);    int numerator()const;    int denomination()const;    ...};//如果operator*写成Rational成员函数的话:class Rational{public:    ...    const Rational operator*(const Rational& rhs)const;    ...};Rational oneEigth(1,8);  //很好Rational oneHalf(1,2);   //很好Rational result = oneHalf * oneEighth;  //很好result = result * oneEighth //很好//当尝试混合运算时：result = oneHalf*2;   //result = oneHalf.operator*(2);很好result = 2*oneHalf;   //result = 2.operator*(oneHalf);出错,继续尝试non-member函数//当编译器试图调用non-member函数 result = operator*(2, oneHalf);时//依旧没有找到对应的non-member函数，因此最终导致出错。//【所以我们应该实现一个这样的non-member函数】：const Rational operator*(const Rational& lhs,const Rational& rhs){    return Rational(lhs.numerator()*rhs.numerator(),                lhs.denomination()*rhs.denomination());}

#2.决定上述non-member函数是non-friend函数还是friend函数的理由是
“是否必须对class内部private成员或protected成员进行访问”，
若需要，则该non-member函数应是friend函数，
若不需要，为满足最大封装性原则，该non-member函数应是non-friend函数。
____________________________________________________________________________________________________________________________________
条款25：考虑写出一个不抛出异常的swap函数
#1.如果swap的缺省实现码对你的class或class template提供了可接受的效率，
请使用该缺省实现版:

namespace std{    template<typename T>    void swap(T&a, T&b)        //std:swap的典型实现    {                           //置换a和b的值        T temp(a);        a = b;        b = temp;    }}

反之，如果因class或class template使用了pImp手法(pointer to implementation):

class WidgetImpl{public:    ...private:    int a, b, c;    std::vector<double> v;    ...};class Widget{public:    Widget(const Widget& rhs);    Widget& operator=(const Widget&rhs)    {        ...        *pImv = *(rhs.pImpl);        ...    }    ...private:    WidgetImpl* pImv;};

从而引起了效率不足，请做以下几件事来提高效率：
(1).提供一个public swap member函数:

//pImv是private成员变量，所以要从内部来swap,//当然也可用friend,但这样的写法和STL一致class Widget{public:    ...    void swap(Widget& other)    {        using std::swap;        swap(pImpl, other.pImpl);    }    ...};//该swap函数保证了异常安全性和高效性，因为swap置换的是指针，对于指针//和内置类型的置换操作绝不会抛出异常，并且还很高效。如果是对自定义类型//执行swap函数，则会因为copy构造函数和copy assignment操作符而允许抛出异常。

(2).在你的class或template所在的namespace(如果没有，则是globe)内提供一个
non-member swap函数,并令它调用上述的swap函数，例如：

namespace WidgetStuff{    ...    template<typename T>    class Widget {...}    ...    template<typename T>    void swap(Widget<T>& a, Widget<T>& b)    {        a.swap(b);    }}

(3).如果正在编写的是一个class(而非class template),为你的class特化std::swap，
并让它调用你的swap member函数，例如：

namespace std{    template<>    void swap<Widget>(Widget& a, Widget& b)    {        a.swap(b);    }}//=======================================================================// 理由:// 好处是即使客户不慎直接调用了std::swap，至少也能获得一个全特化版的swap函数，// 另外，C++只运行class template偏特化，但不允许function template的偏特化,// 因此无法通过编译（虽然某些编译器错误的接受了它）。//=======================================================================

(4).如果你调用swap,请使用using声明式，以便让std::swap在函数中曝光可见，从
而在swap直接书写调用时可获得如下的效率查找：
<1>.在与class相同的 namespace 中查找swap函数。
<2>.在globe坏境中查找swap函数。
<3>.在namesapce std中查找全特化swap函数(如果是class而非template,并且予以了实现）
<4>.在namesapce std中查找一般swap函数。

#2.在std内进行std templates全特化是好的，但千万不要在std内加入一些对于std
来说全新的东西，因为C++标准委员会禁止加入那些已经声明好的东西，即便通过了
编译和执行，其行为也不能得到明确。
____________________________________________________________________________________________________________________________________

（五）.实现

____________________________________________________________________________________________________________________________________

条款26：尽可能延后变量定义式的出现时间
#1.尽可能延后变量定义式的出现，如果可以，要直到初始化为止。
理由1：增加程序的可读性，使程序结构更清晰。
理由2：对于用户(或系统)定义类型，过早的定义变量，可能会导致程序在抛出异常，
函数返回等情况下变量没有使用，因此会带来额外的构造和析构成本。
（内置类型的定义，可以用C风格初始化，也可以延迟变量定义时间，为了统一起见，
最好延迟变量定义的时间。）
例如：

std::string encryptPassword(const std::string& password){    using namespace std;    string encrypted;    if(password.length() < MinimumPasswordLength)        throw logic_error("Password is too short");    ...        return encrypted;}//若抛出logic_error异常，encrypted完全未被使用。//所以应改为：std::string encryptPassword(const std::string& password){        if(password.length() < MinimumPasswordLength)        throw logic_error("Password is too short");    using namespace std;    string encrypted(password);    ...    return encrypted;}

#2.方法A和方法B的定义方式各有千秋，如果你知道赋值的成本比“构造+析构”的成本低，
并且注重效率，那么你应该使用方法A。否则，为了保证程序的可读性和易维护性，
你应该使用方法B。

//方法A:定义于循环外Widget w;for(int i=0;i<n;i++){    w = 取决于i的某个值;    ...}//方法B:定义于循环外for(int i=0;i<n;i++){    Widget w(取决于i的某个值);}//做法A:1个构造函数+1个析构函数+n个赋值操作//做法B:n个构造函数+n个析构函数

____________________________________________________________________________________________________________________________________
条款27：尽量少做转型动作
#1.const_cast,dynamic_cast,reinterpret_cast,static_cast转型操作符。
const_cast:常量性转除，唯一有此能力的C++-style转型操作符。
dynamic_cast:主要用来执行”安全向下转型“，也就是用来决定某对象是否归属
于继承体系中的某个类型。它是唯一无法由旧式语句执行的动作，也是唯一可能
耗费重大运行成本的转型动作。
reinterpret_cast:意图执行低级转型，实际动作（及结果）可能取决于编译器，
这也表示它不可移植，例如将一个 pointer to int 转型为一个 int。这一类
转型在低级代码以为很少见。
static_cast:强迫隐式转换，例如
将 non-contst 转型为 const,
将 int 转型为 double,
将 void*指针与 typed指针互转，
将 pointer-to-base 与 pointer-to-derived互转，
但无法将 const 转型为 non-const,因为这个只有const_cast办的到。

#2.如果可以，尽量避免转型，特别是在注重效率的代码中避免dynamic_cast，如果
有个设计需要转型动作，试着发展无需转型的替代设计。
理由1：C++规则的设计目标之一是，保证“类型错误”绝不发生，为避免在任何对象

身上执行不安全，荒谬的操作，请尽量避免转型。

理由2：任何一个类型转换往往令编译器编译出运行期间执行的码，例如：

class Base{...};class Derived:public Base{...};Derived d;Base* pb = &d;//为获取Base*指针值，在运行期间会有个偏移量(offset)添加在Derived*指针身上，//编译器会为此额外编译出运行期间执行的码。（注意：这里的offset并不明确，//因为对象的布局方式和地址计算方式随编译器的不同而不同。)

理由3：dynamic_cast会耗费重大的运行期成本，在深度继承中，单单多次的
”class名称之字符串“的strcmp比较就会耗费一定的效率成本。

【两种避免dynamic_cast转型的替代策略】：
(1).在单一继承中，直接用 derived class 指针替代 base class 接口处理的derived
class 对象，例如：

//假设先Window/SpecialWindow继承体系中只有SpecialWindows才支持闪烁效果，//试着不要这样做：class Window {...};class SpecialWindow:public Window{public:    void blink();    ...};typedef std::vector<std::tr1::shared_ptr<Window>> VPW;VPW winPtrs;...for(VPW::iterator iter = winPtrs.begin();    iter != winPtrs.end();++iter){    if(Specialwindow* psw=dynamic_cast<SpecialWindow*>(iter->get()))        psw->blink();}//应该改成这样:typedef std::vector<std::tr1::shared_ptr<SpecialWindow>> VPW;VPW winPtrs;...for(VPW::iterator iter = winPtrs.begin();    iter != winPtrs.end();++iter){    (*iter)->blink();}

(2).多重继承中，用virtual函数代替dynamic_cast所做的事

//用dynamic_cast时如下所示：class Window {...};...typedef std::vector<std::tr1::shared_ptr<Window>> VPW;VPW winPtrs;...for(VPW::iterator iter = winPtrs.begin();    iter != winPtrs.end();++iter){    if(SpecialWindow* psw1=        dynamic_cast<SpecialWindow*>(iter->get()))psw1>blink();    else if(SpecialWindow* psw2=        dynamic_cast<SpecialWindow*>(iter->get()))psw2->blink();    else if(SpecialWindow* psw3=        dynamic_cast<SpecialWindow*>(iter->get()))psw3->blink();}//以上的做法中有一连串dynamic_cast,这会使产生出来的代码又长又慢，//而且基础不稳，因为继承体系一有改变，所有这一类代码都要检查看看//是否需要修改，例如添加一个新的derived class，则要在一连串判断//中加入新的条件分支，及其不易维护。//所以应该改成这样：class Window {public:    virtual void blink();{}   //缺省实现码什么也没做    ...};class SpecialWindow:public Window{public:    virtual void blink(){...}; //blink做某些事    ...};...typedef std::vector<std::tr1::shared_ptr<Window>> VPW;VPW winPtrs;...          //容器，内含Window指针，指向所有可能的派生类对象for(VPW::iterator iter = winPtrs.begin();    iter != winPtrs.end();++iter){    (*iter)->blink();}

#3.如果转型无可避免，请将它隐藏在函数背后，这样客户调用该函数时，不需要将

转型动作放入它们的代码里，保证了代码的封装性和易维护性。

#4.尽量用C++-style的转型替换旧式转型（构造函数除外），因为
(1).它们很容易在代码中辨别出来，因此简化了“找出类型系统破坏点”的过程。
(2).转型动作分门别类，因此更有利于编译器找出错误的运用。
____________________________________________________________________________________________________________________________________
条款28：若返回 handles 指向对象内部成分，请保证返回值 const 约束大于等于成员函数
#1.References, 指针和迭代器通通都是 handles,用来取得某个对象。
#2.若返回handles指向内部对象，并且成员函数是const,请保证该返回值也是const 。

class Point{public:    Point(int x, int y);    ...    void setX(int newVal);    void setY(int newVal);    ...};struct RectData{    Point ulhc;    Point lrhc;};class Rectangle{    ...private:    std::tr1::shared_ptr<RectData> pData;    Point& upperLeft()const{return pData->ulhc;}    Point& lowerRight()const{return pData->lrhc;}    ...};Point coord1(0,0);Point coord2(100, 100);const Rectangle rec(coord1, coord2);rec.upperLeft().setX(50);//这里返回的handles可以改变，但与upperLeft const()成员函数的本意是相反的。//所以应改成：class Rectangle{    ...private:    ...    const Point& upperLeft()const{return pData->ulhc;}    const Point& lowerRight()const{return pData->lrhc;}    ...};//这样就可以在保证读写权的同时禁止涂写权。

【本条为个人观点：】
#3.对于返回值为自定义(或系统定义）类型的non-const成员函数，返回内部成员
变量的handles(non-const)表示希望该内部变量是public，而对于返回值为内置
类型的成员变量，则该使用pass-by-valued的getXXX()函数和setXXX(X)来分别
区分读写行为。
例如：

//当upperLeft(),lowerRight()为non-const时：class Rectangle{    ...private:    ...    Point& upperLeft(){return pData->ulhc;}    Point& lowerRight(){return pData->lrhc;}    ...};Point coord1(0,0);Point coord2(100, 100);Rectangle rec(coord1, coord2);//我们可以如下这样用函数统一接口设置值和得到值:rec.upperLeft().setX(50);int val = rec.lowerRight().getY();

____________________________________________________________________________________________________________________________________
条款29：为”异常安全“而努力是值得的
#1.异常安全函数即使发生异常也不会泄露资源或允许任何数据败坏。
这样的函数区分三种可能的保证：基本型，强烈型，不抛异常性。
(1).基本型：异常抛出后，class一切约束条件满足，程序内事物处于一种有效的状态中。
(2).强烈保证型：异常抛出后，程序状态不改变，函数回到调用前的状态。
(3).不抛异常型：保证不抛出任何异常，对内置类型（int,指针，等）身上的所有操作
都提供nothrow保证。
（任何使用动态内存的东西在无法满足内存需求下，都会抛出bad_alloc异常）

#2.除非调用传统非安全异常安全码，否则应保证异常安全，因为传统非异常安全码
不具备异常安全性，所以任何调用它的代码都不具备异常安全性，因此为其撰写
异常安全码是么有任何意义的。

#3.”强烈保证“往往能够以 copy-and-swap实现出来。

//一个用copy-and-swap的示例：struct PMImpl{            //PMImpl = PrettyMenu Impl    std::tr1::shared_ptr<Image> bgImage;    int imageChanges;};class PrettyMenu{    ...private:    Mutex mutex;    std::tr1::shared_ptr<PMImpl> pIml;};void PrettyMenu::changeBack(std::istream& imgSrc){    using std::swap;    Lock ml(&mutex);        //获得mutex的副本数据    std::tr1::shared_ptr<PMImpl> pNew(new PMImpl(*pImpl));    pNew->bgImage.reset(new Image(imgSrc)); //修改副本    ++pNew->ImageChanges;    swap(Impl, pNew);        //置换(swap)数据，释放mutex}//，但”强烈保证“ 并非对所有函数都具有可实现或具备实现意义:

(1).因为如copy-and-swap这样的强烈保证往往会耗费更多的时间和空间，为了
保证更好的效率，应以”基础保证“来替换，这样才更具现实意义。

(2).当函数对”非局部性数据”有影响时，提供强烈保证就很难了。

void someFunc{    ...     //对local状态做一份副本    f1();    f2();    ...     //将修改后的状态置换过来}//假设someFunc对“局部数据”提供强烈保证，但f1(),f2()对someFunc()来说是//非局部性的”，因此f1(),f2()会对someFunc()的强烈保证期望造成影响，//假设f1(),f2()提供一个基本保证，显然someFunc将只会提供基本保证，//而若f1(),f2()也提供强烈保证，但若f1(),f2()并未抛出异常，在此之后//却抛出了异常，那么someFunc()也无法提供强烈保证，毕竟程序状态改变了。//另一方面，在someFunc中像某些数据库之类的非局部数据一旦被改变，想恢复//就很困难，这时someFunc想提供强烈保证就真的很难了。

#4.函数提供的“异常安全保证”最多只等于其所调用之各个函数的“异常安全保证”

中的最弱者（从上述例子中可以看出）。

____________________________________________________________________________________________________________________________________