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++标准委员会禁止加入那些已经声明好的东西,即便通过了
编译和执行,其行为也不能得到明确。
____________________________________________________________________________________________________________________________________
(五).实现
____________________________________________________________________________________________________________________________________
#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.函数提供的“异常安全保证”最多只等于其所调用之各个函数的“异常安全保证”
中的最弱者(从上述例子中可以看出)。
____________________________________________________________________________________________________________________________________
郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。