条款26：尽可能延后变量定义式的出现时间
- 考察下面的示例代码：
void Foo()
{
std::string myStr;
if (条件) {
// 没用用到myStr
return;
}
// 使用myStr变量的代码
}
很显然，这里的myStr提前定义了，并且会带来额外的默认构造函数的开销，虽然在这个例子中微乎其微。
-
在定义一个类对象时，尽可能使用其带参数的构造函数，而不是先使用默认构造函数然后再使用赋值语句操作。
-
在for循环中用到的临时变量最好是在循环体中定义，这样做的好处是临时变量的作用域只在循环体中，避免了与外部变量的冲突。
for (int i = 0; i < N; i++) {
MyClass obj; // 在循环体内定义变量，这是建议的做法。
// 循环体代码
}
条款27：尽量少做转型动作
C++中新型的类型转换有：
- const_cast：用于去掉const变量的const属性，但是如果通过转换后的非const指针去修改一个const变量是造成未定义的后果。
const int val = 100;
int *p = const_cast<int*>(&val);
*p = 101; // undefined behavior
详见：https://en.cppreference.com/w/cpp/language/const_cast
PS：个人觉得const_cast有点让人摸不着头脑，不知道为啥要设计这个转换。
- dynamic_cast：“安全向下”转型，用于将一个基类型指针转换为子类型指针，存在额外开销，并且需要判断转换后的结果是否为空。
class B {
public:
B() {}
virtual ~B() {}
};
class D : public B {
};
int main()
{
B* pb1 = new D();
B* pb2 = new B();
D* pd1 = dynamic_cast<D*>(pb1);
if (pd1 != nullptr) {
std::cout << "pd1 is ref to D obj" << std::endl;
} else {
std::cout << "pd1 is not ref to D obj" << std::endl;
}
D* pd2 = dynamic_cast<D*>(pb2);
if (pd2 != nullptr) {
std::cout << "pd2 is ref to D obj" << std::endl;
} else {
std::cout << "pd2 is not ref to D obj" << std::endl;
}
return 0;
}
- reinterpret_cast：常用于重新解释一个数据结构，存在比较大的安全风险。
- statitc_cast：对应于C语言的中强制转换。
使用建议：
- 尽可能使用C++新的转型关键字
- 如无必要，尽量减少转型，特别是dynamic_cast这种转换，影响性能。
条款28：避免返回handles指向对象内部成分
- 一个类中如果定义了private成员变量，但同时又通过public成员函数返回了其指针或者引用，这样就会间接的破坏了类的封装性，原本private成员变量会被外部客户直接使用。
- 返回类中成员变量的引用或者指针时，会增加“悬垂指针”问题的产生的风险。因为，当外部代码获取到这些引用或者指针后，其对应的类实例对象可能在其它地方已经释放了。
条款29：为“异常安全”而努力是值得的
异常安全的函数需要实现以下要求：
- 不泄露任何资源：当异常发生后，之前分配的资源不应该没有释放。
- 不允许数据败坏，主要是异常发生后要保证数据的一致性。
异常安全有三个级别的承诺：
- 基本承诺：异常发生后，系统的状态不会出现不一致的情况，但是具体是什么状态无法保证。
- 强烈保证：要么完全成功，要么退回到函数调用前的状态。
- 不抛异常保证：函数执行过程中保证不产生异常。
常用的异常安全实现方法是“copy and swap”方法，该方法步骤如下：
1、为你将要修改的对象，先建立一个副本；
2、在副本上进行需要的修改；
3、将原对象与副本对象进行置换操作，并且保证调用的是一个不会抛出异常的swap操作，通常是两个指针变量之间的交换；
条款30：透彻了解inlining的里里外外
- inline函数的好处是可以像函数那样调用，但是却没有函数调用的开销；
- 带来的问题是会增加程序代码的大小，因为会在调用的地方展开。所以一般是将常用的并且短小的函数设置成inline。
- class类定义体中的实现函数默认设置成inline方式。
- 函数模板不要设置成inline方式，虽然一般是在头文件中定义。
条款31：将文件间的编译依存关系降至最低
我们在声明一个类时，如果成员变量中包含了其它类时，则需要引用（include）其它类的头文件，因为编译器在编译这个类时需要知道每个成员变量占用多大的空间。在这里，该类的声明就在编译层面与其它类产生了依存关系。
为了减少这种依存关系，在类的定义中需要避免在成员变量中定义其它类的对象，如果一定要定义，最好采用引用或者指针（包括智能指针）形式。这时候，可以在类的头文件中采用前置声明的方式来引用其它类，而不是直接inlcude其它头文件。
举例：存在一个Date类表示日期，Address类表示地址，以及Person类表示一个人，并且提供获取此人生日和地址的方法。
- Date.h
#ifndef UNTITLED6_DATE_H
#define UNTITLED6_DATE_H
class Date {
};
#endif //UNTITLED6_DATE_H
- Address.h
#ifndef UNTITLED6_ADDRESS_H
#define UNTITLED6_ADDRESS_H
class Address {
};
#endif //UNTITLED6_ADDRESS_H
- Person.h
#ifndef UNTITLED6_PERSON_H
#define UNTITLED6_PERSON_H
class Address; // 前置声明
class Date; // 前置声明
class Person {
public:
Address GetAddr();
Date GetDate();
};
#endif //UNTITLED6_PERSON_H
- Person.cpp
#include "Person.h"
#include "Address.h"
#include "Date.h"
Address Person::GetAddr()
{
Address tmp;
return tmp;
}
Date Person::GetDate()
{
Date tmp;
return tmp;
}
可以看到Person.h中并没有include Date.h以及Address.h，但是在cpp实现文件中需要引用涉及到的类头文件。
通过这种方式，将类的编译从相依于定义式转变为相依于声明式。
在接口类的设计中，为了尽可能降低接口类编译的依存关系，也采用了这种思路，有两种做法：
- handle class：在接口类中定义一个实现类的handle（引用或者指针），由实现类完成与其他类的编译依存关系。
- interface class：接口类只包含虚函数功能接口，由具体的实现类继承接口类进行实现，采用简单工厂模式创建具体的实现类对象。
网友评论