《effective c++》学习笔记(五)
2017-08-27 22:17
218 查看
尽可能延后变量定义式出现的时间
对象的声明周期需要经过构造和析构,考虑下面这份代码void foo(bool flag) { string str; if (flag) { return ; } // something }
当flag是true的时候,实际上我们浪费了一次构造string的时间,因为这个string构造了但是根本没有用到,所以我们最好将变量定义到用到它的前一刻最好。
但对于循环来说,比如这份例子
// 方案1 void foo(int n) { Bar b; for (int i = 0;i < n;++i) { b.x = i; // something } } // 方案2 void foo(int n ) { for (int i = 0;i < n;++i) { Bar b(i); // something } }
方案1中,需要1次默认构造函数 + n次拷贝函数 + 1次析构函数
方案2中,需要n次拷贝构造函数 + n次析构函数
所以在遇到循环时,需要判断拷贝函数和构造 + 析构函数哪个效率更高,如果是拷贝函数效率更高那么使用方案1,如果是构造 + 析构效率更高,那么使用方案2
尽可能延后变量定义式的出现。这样做可增加程序的清晰度并改善程序效率
尽量少做转型动作
C++中应该尽量少做转型动作,一是为了避免降低效率,二是为了减少代码出错概率,考虑下面这份代码:class Base { public: void foo() { // something } }; class Derived : public Base{ public: void foo() { static_cast<Base>(*this).foo(); // 注意这里 } };
上述代码中期望Derived中的foo可以调用Base中的foo,然而事实是:static_cast会生成一个临时的Base对象,然后调用那个临时的Base对象的foo成员,而不是调用this对象中Base部分的foo成员。正确的写法应该是下面这样:
class Base { public: void foo() { // something } }; class Derived : public Base{ public: void foo() { Base::foo(); } };
如果可以,尽量避免转型,特别是在注重效率的代码中避免dynamic_cast。如果有个设计需要转型动作, 试着发展无需转型的替代设计
如果转型是必要的,试着将它隐藏于某个函数背后。客户随后可以调用该函数,而不需将转型放进他们自己的代码内
宁可使用c++-style转型,不要使用旧式转型。前者很容易辨识出来,而且也比较有着分门别类的职掌
避免返回handles指向对象的内部成分
考虑下面这份代码:class Foo { public: int& get_x() { return x; } private: int x; };
很容易可以发现,虽然x的private级别,但可以通过get_x得到这个对象,那么实际上x的级别被提升到public级别了,这个private并没有意义。
对于成员函数,也是同样的道理
避免返回handles指向对象内部。遵守这个条款可增加封装性,帮助const成员函数的行为像个const,并将发生“虚吊号码牌”的可能性降至最低
为“异常安全”而努力是值得的
对于一个函数的异常性,我们有三种方案基本承诺:如果异常被抛出,程序内的任何事物仍然保持在有效状态
强烈保证:如果异常被抛出,程序状态不改变
不抛掷保证:承诺绝不抛出异常
有一个一般化的设计叫做 copy and swap。原则很简单:为你打算修改的对象复制一份副本,然后再那副本上进行修改,最后再进行一次swap。
异常安全函数即使发生异常也不会泄漏或允许任何数据结构破坏。这样的函数区分三为三种可能的保障:基本型、强烈性、不抛异常型
“强烈保证”往往能够以copy-and-swap实现出来,但“强烈保证”并非对所有函数都可实现或具备现实意义
函数提供的“异常安全保证”通常最高只等于其所调用之各个函数的“异常安全保证”中的最弱者
透彻了解inlining的里里外外
将大多数inlining限制在小型、被频繁调用的函数身上。这可使日后的调试过程和二进制升级更容易,也可使潜在的代码问题最小化,使程序的速度提升最大化不要只因为function templates出现在头文件,就将它们声明为inline
将文件间的编译依存关系降至最低
考虑下面两份代码:class Person { public: Person(const std::string& name,const Date& birthday,const Address& addr); std::string name() const; std::string birthDate() const; std::string address() const; ... private: std::string theName; Date theBirthDate; Address theAddress; }; ============================= namespace std { class string; } class Date; 4000 class Address; class Person { public: Person(const std::string& name,const Date& birthday,const Address& addr); std::string name() const; std::string birthDate() const; std::string address() const; ... };
当Date的定义改变时(接口不改变),第一份代码会重新编译,进而依赖第一份代码的文件也会重新编译,而第二份代码则不会重新编译。
所以为了避免编译依赖,可以使用一种叫做pimpl的手法,即声明和实现分开写,比如上面的代码可以定义两个类Person和PersonPIMPL,其中具体实现写在PersonPIMPL中:
class PersonIMPL; class Person { public: string get_name(); private: shared_ptr<PersonIMPL> _data; }; class PersonIMPL { public: string get_name() { return name; } private: string name; }; string Person::get_name() { return _data->get_name(); }
这样便可以将声明和定义分开。
当然也可以使用抽象基类来实现接口和实现的分离:
class Person { public: virtual string get_name() = 0; virtual ~Person() { }; }; class PersonIMPL : public Person { public: string get_name() { return name; } private: string name; };
但这样要求使用的时候必须使用Person的指针或引用才可以。
支持“编译依存性最小化“的一般构想是:相依与声明式,不要相依于定义式。基于此构想的两个手段是Handle classes和Interface classes
程序库头文件应以“完全且仅有声明式”形式存在,这种做法不论是否涉及templates都适用
相关文章推荐
- 《Effective C++》学习笔记——条款29
- 《effective c++》学习笔记(一)
- 《effective c++》学习笔记(四)
- 《effective c++》学习笔记(五)
- 《effective c++》学习笔记(七)
- 《Effective C++》学习笔记——条款37
- 《Effective C++》学习笔记——条款44
- 《Effective C++》学习笔记条款17 以独立语句将newed对象置入智能指针
- 《Effective C++》学习笔记(八)
- 《Effective C++》学习笔记
- 《Effective C++》学习笔记——条款28
- 《effective c++》学习笔记(一)
- 《effective c++》学习笔记(四)
- 《effective c++》学习笔记(五)
- 《effective c++》学习笔记(七)
- 《Effective C++》学习笔记条款01 视C++为一个语言联邦
- 《Effective C++》学习笔记条款18 让接口容易被正确使用,不易被误用
- 《Effective C++》学习笔记(1)
- 《effective c++》学习笔记(一)
- 《effective c++》学习笔记(四)