本系列是开源书C++ Best Practises的中文版，全书从工具、代码风格、安全性、可维护性、可移植性、多线程、性能、正确性等角度全面介绍了现代 C++项目的最佳实践。本文是该系列的第六篇。
C++最佳实践:
性能
尽量使用前置声明
使用这种声明方式:
// some header file class MyClass; void doSomething(const MyClass &);
而不是这样:
// some header file #include "MyClass.hpp" void doSomething(const MyClass &);
同样也使用于模板:
template<typename T> class MyTemplatedType;
这种方式可以主动减少编译时间并重新构建依赖关系。
注意: 前置声明会阻碍内联和优化，建议在发布版本中使用链接时优化或链接时代码生成。
避免不必要的模板实例化
模板不要随便实例化，实例化过多模板，或者模板代码多于必要的数量，会增加编译代码的大小和构建时间。
避免递归模板实例化
递归模板实例化可能会给编译器带来很大的负担，并且代码更加难以理解。
分析构建
可以使用Templight工具分析项目的构建时间，它需要花一些时间来构建，但一旦这样做了，可以用来替换 clang++。
使用 Templight 进行构建之后，需要对结果进行分析，templight-tools项目提供了各种方法(建议使用 callgrind 转换并使用 kcachegrind 对结果进行可视化)。
隔离频繁更改的头文件
不要包含不需要的头文件
编译器必须处理看到的每个 include 指令，即使只是在看到#ifndefinclude 保护符后立即停止，仍然必须打开文件并进行处理。
include-what-you-use是一个可以帮我们确定需要哪些头文件的工具。
减少预处理器的工作
这是“隔离频繁更改的头文件”和“不要包含不需要的头文件”的一般形式。类似 BOOST_PP 这样的工具可能非常有用，但也给预处理器带来了巨大的负担。
考虑使用预编译头文件
使用预编译头文件可以大大减少大型项目的编译时间，选定的头文件被编译成中间形式(PCH 文件)，编译器可以更快处理。建议只将经常使用但很少更改的头文件定义为预编译头文件(例如系统头文件和库头文件)，以减少编译时间。但必须记住，使用预编译头文件有几个缺点:
- 预编译头文件不可移植。
- 生成的 PCH 文件依赖于机器。
- 生成的 PCH 文件可能相当大。
- 它会破坏头文件依赖关系。由于有预编译头文件，每个文件都有可能包含标记为预编译头文件的每个头文件。因此，如果禁用预编译头文件，可能会导致构建失败。如果需要发布库之类的项目，这可能是个问题。正因为如此，强烈建议在第一次构建时启用预编译头，而在后续构建时将其关闭。
大多数常见的编译器都支持预编译头文件，比如GCC、Clang和Visual Studio。像cotire(cmake 的插件)这样的工具可以帮助我们在构建系统中添加预编译的头文件。
考虑使用工具
工具并不意味着可以取代好的设计。
将 tmp 放在 Ramdisk 上
详见 YouTube 视频: https://www.youtube.com/watch?v=t4M3yG1dWho
使用 gold 链接器
如果是在 Linux 上，考虑使用 GCC 的 gold 链接器(ld.gold)。
参考: gold: Google Releases New and Improved GCC Linker
运行时
分析代码
在不分析代码的情况下，无法真正找到瓶颈在哪里。
简化代码
代码越清晰、越简单、越容易阅读，编译器就越有可能更好的将其实现。
使用初始化列表
// This std::vector<ModelObject> mos{mo1, mo2}; // -or- auto mos = std::vector<ModelObject>{mo1, mo2};
// Don't do this std::vector<ModelObject> mos; mos.push_back(mo1); mos.push_back(mo2);
通过减少对象复制并调整容器大小，初始化列表能显著提升性能。
减少临时对象
// Instead of auto mo1 = getSomeModelObject(); auto mo2 = getAnotherModelObject(); doSomething(mo1, mo2);
// consider: doSomething(getSomeModelObject(), getAnotherModelObject());
这类代码将阻碍编译器执行 move 操作……
启用移动(move)操作
move 操作是 C++11 中最受欢迎的特性之一，该操作允许编译器通过移动临时对象从而避免额外的拷贝。
某些代码(例如声明自己的析构函数或赋值操作符或拷贝构造函数)会阻止编译器生成移动构造函数。
对于大多数代码，下面这么一个简单的定义:
ModelObject(ModelObject &&) = default;
...就足够了，不过 MSVC2013 似乎不支持这段代码。
避免shared_ptr拷贝
shared_ptr对象的拷贝成本比想象的要高得多，因为引用计数必须是原子的和线程安全的。这条规则只是再次强调了上面的注意事项: 避免临时对象和过多的对象副本。仅仅因为我们使用了 pImpl，并不意味着副本没有代价。
尽可能减少拷贝和重分配
对于更简单的情况，可以使用三元操作符:
// Bad Idea std::string somevalue; if (caseA) { somevalue = "Value A"; } else { somevalue = "Value B"; }
// Better Idea const std::string somevalue = caseA ? "Value A" : "Value B";
使用立即调用的lambda可以简化更复杂的情况。
// Bad Idea std::string somevalue; if (caseA) { somevalue = "Value A"; } else if(caseB) { somevalue = "Value B"; } else { somevalue = "Value C"; }
// Better Idea const std::string somevalue = [&]( "&"){ if (caseA) { return "Value A"; } else if (caseB) { return "Value B"; } else { return "Value C"; } }();
避免多余的异常
在正常处理期间，内部抛出和捕获的异常会降低应用程序的执行速度。由于调试器会监视和报告每个异常事件，因此还会破坏调试器的用户体验。最好尽可能避免内部异常处理。
抛弃new
我们已经知道不该使用裸内存访问，因此改用unique_ptr和shared_ptr，对吧？堆分配比栈分配昂贵得多，但有时不得不用。更糟的是，创建shared_ptr实际上需要在堆上分配 2 次。
然而，make_shared函数可以将其减少为一次。
std::shared_ptr<ModelObject_Impl>(new ModelObject_Impl()); // should become std::make_shared<ModelObject_Impl>(); // (it's also more readable and concise)
优先选择unique_ptr而不是shared_ptr
可能的话，使用unique_ptr而不是shared_ptr。unique_ptr是不可复制的，因此不需要跟踪副本，比shared_ptr性能更好。另外，类似于shared_ptr和make_shared的关系，应该使用make_unique(C++14 或更高版本)来创建unique_ptr:
std::make_unique<ModelObject_Impl>();
目前的最佳实践也建议从工厂函数返回unique_ptr，然后在必要时将unique_ptr转换为shared_ptr。
std::unique_ptr<ModelObject_Impl> factory(); auto shared = std::shared_ptr<ModelObject_Impl>(factory());
抛弃std::endl
std::endl表示刷新操作，等价于"\n" << std::flush。
限制变量作用域
变量应该尽可能晚声明，最好只在可以初始化对象时声明。减小变量作用域可以减少内存的使用，提高代码效率，并帮助编译器进一步优化代码。
// Good Idea for (int i = 0; i < 15; ++i) { MyObject obj(i); // do something with obj } // Bad Idea MyObject obj; // meaningless object initialization for (int i = 0; i < 15; ++i) { obj = MyObject(i); // unnecessary assignment operation // do something with obj } // obj is still taking up memory for no reason
对于 C++17 及以后版本，考虑在if和switch语句中初始化变量:
if (MyObject obj(index); obj.good()) { // do something if obj is good } else { // do something if obj is not good }
优先选择double类型而不是float类型，但需要先测试
根据情况和编译器的优化能力，一种可能比另一种更快。选择float意味着精度较低，并可能由于类型转换而影响性能。在可向量化操作中，如果能够牺牲精度，float可能更快。double是 C++中浮点值的默认类型，因此推荐作为默认选项。
优先选择++i而不是i++
...当语义正确时，前置自增比后置自增更快，因为前置自增不需要创建对象副本。
// Bad Idea for (int i = 0; i < 15; i++) { std::cout << i << '\n'; } // Good Idea for (int i = 0; i < 15; ++i) { std::cout << i << '\n'; }
即使许多现代编译器将这两个循环优化为相同的汇编代码，选择++i仍然是一种良好的实践。你永远无法确定代码会不会使用不带优化的编译器，因此没有任何理由不这样做。此外，编译器有可能只对整数类型进行优化，而不一定对所有迭代器或其他用户自定义类型进行优化。
总而言之，如果前置自增操作符与后置自增操作符在语义上相同，那么使用前置自增操作符总是更好。
char 是 char, string 是 string
// Bad Idea std::cout << someThing() << "\n"; // Good Idea std::cout << someThing() << '\n';
看上去区别不大，但是"\n"必须被编译器解析为const char *，必须在写入流(或附加到字符串)时对\0进行范围检查，而'\n'是已知的单个字符，可以节约许多 CPU 指令。
如果多次调用效率低下的代码，可能会对性能产生影响，更重要的是，考虑这两种使用情况会让我们更多的考虑编译器和运行时在执行代码时必须做什么。
永远不要用std::bind
std::bind的开销(包括编译时和运行时)几乎总是比需要的更多，相反，我们只需使用 lambda。
// Bad Idea auto f = std::bind(&my_function, "hello", std::placeholders::_1); f("world"); // Good Idea auto f = [](const std::string &s) { return my_function("hello", s); }; f("world");
了解标准库
正确使用供应商提供的标准库中已经高度优化的组件。
in_place_t及相关内容
知道如何使用in_place_t和相关标签高效创建诸如std::tuple、std::any和std::variant等对象。
