《Effective C++》- 极精简版 41-55条

本文章属于专栏《业界Cpp进阶建议整理》

继续上篇《Effective C++》- 极精简版 31-40条。本文列出《Effective C++》的41-55条的个人理解的极精简版本。

40、谨慎使用多重继承
- 个人见解：这是一个性价比不高的功能，容易出错，且收益不高。java语言中也没有多继承。放弃它吧。

41、了解隐氏接口和编译期多态
- 基类纯虚函数，子类就可以实现这个纯虚函数，保证所有继承该基类的子类都有相同的接口
- 编译器多态：函数重载、模版、宏可以实现。
- 个人见解：放弃编译时期宏的多态，容易出错，且难以维护
42、了解typename的双重含义
- 声明template参数时，关键字class和typename的意义完全相同
- 在模版中，要使用A的嵌套类，需要用typename A::xx。否则编译器无法确定xx是嵌套类还是成员变量
- typename不能修饰继承的基类列表和成员函数初始化列表（其实是因为这两个地方语义已经明确，不需要区分）
- 个人见解：向STL源码学习，模版使用关键字typename + 模版中使用嵌套类时前面加上typename
43、学习处理模版化基类内的名称
- 继承模版基类时，必须是继承特化的基类。如果想使用非特化的基类函数，用this->Base_fun()。
44、将于参数无关的代码抽离template
- 核心考虑如果，各个模版实例化后，都会调用相同成员函数逻辑，而diff仅仅是参数值不同，那可以考虑这个成员函数以输入参数的形式，而不是模版参数的形式，防止二进制膨胀
- 如template<typename T, size_t n>，这里的n尽量不要作为模版参数，否则容易生成特别的实际代码，导致二进制很大。不要让模版数量和参数值产生依赖关系
- 个人见解：除需要类型判断的变量，能写成函数参数的，就不用模版参数。
45、让成员函数接受所有兼容的类型
- 个人见解：同一个成员函数对不同类型处理逻辑一样时，用模版，而不是overload
46、需要类型转换时请为模版定义非成员函数
- 对operator*，如24条，只有定义为非成员函数才能 2*a完成隐式转换。但是必须是friend函数，才能在template形式的类完成类型推导。但是模版的声明和定义要在一起，所以这个时候需要一个在class内部的friend模版函数
47、traits class表现类型信息
- 这里使用traits，是为了在编译时知道模版传进来的参数类型。理论上可以用传入的对象的参数，但是为了同时适配内置类型，C++遵守一个共同的协议，通过typedef在特化模版函数中写，通过typeid()函数读。
- 个人见解：尽量不使用，而是使用基类的成员变量来判断。因为typeid 会引入运行时开销
48、认识模版元编程TMP（template metaprogramming）
- 概念：是由c++写的，执行于c++编译器内的程序。它的输出是若干c++源码
- 优势：更小的可执行文件、较短的运行周期、较少的内存需求。
- 个人见解：部分场景有性能收益，但是维护成本高，代码不易读，更长的编译时间。

49、了解new-handler的行为
- operator new无法满足内存分配需求时，operator new会抛出异常，在抛出异常之前，会先调用用户通过set_new_handler指定的void ()函数。
- 个人见解：不常用，内存分配不出来的时候，服务大概率以及接近不可用的状态了。
50、了解new和delete的合理替换时机
- 用来检测运用上的错误、为了强化效率、为了收集使用上的统计数据
- 为了效率，比如tcmalloc、jemalloc
- 个人见解：在海量数据处理的服务，对性能提升很大，十分重要。可以参考我之前写的《c++的高性能内存管理库tcmalloc和jemalloc》
51、编写new、delete时需要固守的常规
- 个人见解：不要改，用tcmalloc或jemalloc的
52、重新定义new之后，一定要重新定义delete
- 个人见解：不要改，能绕过就绕过
53、不要忽略编译器的警告
- 个人见解：三方库质量、版本参差不齐，告警十分常见。实践中只关注自己的代码告警吧，稳定性依赖其他方式，一个个解决三方库的告警，是在浪费时间
54、让自己熟悉包括TR1在内的标准库
- 独立机制：shared_ptr、function、bind、Hash tables、正则表达式、Tuples、array、mem_fn、reference_wrapper、随机数生成工具、数学特殊函数
- template编程技术：Type traits、result_of
55、熟悉boost