《Effective C++》学习笔记——条款30

最新推荐文章于 2022-08-16 08:29:16 发布

ltree98

最新推荐文章于 2022-08-16 08:29:16 发布

阅读量1.1k

点赞数

分类专栏： Effective C++ 文章标签： Effective C++ 学习笔记条款30 inline

本文链接：https://blog.csdn.net/lttree/article/details/45148521

版权

Effective C++ 专栏收录该内容

45 篇文章 5 订阅

订阅专栏

***************************************转载请注明出处：http://blog.csdn.net/lttree********************************************

五、Implementations

Rule 30：Understand the ins and outs of inlining

规则 30：透彻了解inlining的里里外外

1.inline 的优缺点

> 优点

——看起来像函数

——动作像函数

——比宏好很多

——可以调用它们又不需要蒙受函数调用所招致的额外开销

——编译器最优化机制通常被设计用来浓缩那些“不含函数调用”的代码，所以当你inline某个函数，或许编译器就因此——有能力对它（函数本体）执行预警相关最优化。大部分的编译器不会对一个“outlined函数调用”动作执行如此之最优化

> 缺点

——可能增加目标码（object code）的大小

——inline造成的代码膨胀会导致额外的换页行为，降低指令告诉缓存装置的击中率，以及伴随这些而来的效率损失

2.观点

记住—— inline只是对编译器的一个申请，不是强制命令。

> 声明

这项申请可以隐喻的提出，也可以明确的提出。

隐喻方式是将函数定义于class定义式内：

class Person  {
public:
    ...
    // 一个隐喻的inline申请：age被定义于class定义式内
    int age() const  {  return theAge;  }
    ...
private:
    int theAge;
};

在条款46中会提到，friend函数也可以定义于class内，所以它们也是被隐喻声明为 inline

明确声明做法则是在其定义式前加上关键字inline。例如标准的max template（来自<algorithm>）往往这样实现：

template<typename T>
inline const T& std::max(const T& a,const T& b)
{  return a<b?b:a;  }

> inline and template

inline函数和 template 两者通常都被定义在头文件内，这使得某些程序员认为 function template 一定必须是inline，有必要好好看一下这两者:

——Inline函数通常一定被置于头文件内，因为大多数建置环境在编译过程中进行inlining，而为了将一个“函数调用”替换为“被调用函数的本体”，编译器必须知道那个函数长什么样子。某些建置环境可以再连接期完成inlining，少量建置环境如基于.NET CLI；公共语的托管环境竟可在运行期完成inlining。

inlining在大多数C++程序中是编译器行为。

——Template 通常也被置于头文件内，因为它一旦被使用，编译器为了将它具现化，需要知道它长什么样子。

Template的具现化与inlining无关。如果你写的template没有理由要求它所具现的每一个函数都是inlined，就应该避免将这个template声明为inline。

因为inline需要成本，在缺点中提到过代码膨胀，但还存在其他的成本。

3.于编译器角度看 inline

一个表面上看似inline的函数是否真是inline，取决于你的建置环境，主要取决于编译器。

幸运的一件事——大多数编译器提供了一个诊断级别：如果它们无法将你要求的函数inline化，会给一个warning

> 大部分编译器拒绝将太过复杂（含有循环或递归）的函数inlining，而所有对virtual函数的调用也都会使inline落空。

因为virtual意味着“等待，直到运行期才确定调用哪个函数”，而inline意味着“执行前，先将调用动作替换为被调用函数的本体”。编译器根本不知道你调用哪个函数，如何替换？

> 有时候虽然编译器有意愿inlining某个函数，还是可能为该函数生成一个函数本体。

比如，如果程序要取某个inline函数的地址，编译器通常必须为此函数生成一个 outlined 函数本体。毕竟编译器无法让一个指针指向并不存在的函数。

而且，编译器通常不对“通过函数指针而进行的调用”实施inlining，这意味对inline函数的调用可能被inlined，取决于该调用的实施方式：

// 假设编译器有意愿inline“对f的调用”
inline void f()  {  ...  }  
// pf 指向 f
void (*pf)() = f;
...
// 这个调用将被inlined，因为他是一个正常调用
f();
// 这个调用或许不被inlined，因为它通过函数指针达成
pf();

实际上构造函数和析构函数往往是inlining的糟糕候选人——虽然漫不经心的情况下你不会这么认为。

class Base  {
public:
    ...
private:
    std::string bm1,bm2;
};
class Derived : public Base  {
public:
    Derived()  {  }
    ...
private:
    std::string dm1,dm2,dm3;
};

这个构造函数看起来是inlining的候选人，因为它根本不包含任何代码。

但事实并不如此！

C++对于“对象被创建和被销毁时发生什么事”做了各式各样的保证。

当你使用 new，动态创建的对象被其构造函数自动初始化；当你使用delete，对应的析构函数会被调用。

当你创建一个对象，其每一个base class以及每一个成员变量都会被自动构造；当你销毁一个对象，反向程序的析构行为亦会自动发生。

如果有个异常在对象构造期间被抛出，该对象已构造好的那一部分会被自动销毁。

在这些情况中C++描述了什么一定会发生，但没有说如何发生。

“事情如何发生”是编译器实现者的权责，它们不可能凭空发生，在我们的程序中一定有某些代码让那些事情发生。

这些代码有时候放在你的构造函数和析构函数内，所以，我们可以想象到，编译器为上面那个看起来是空的Derived构造函数所产生的代码，应该是这样的：

Derived::Derived()
{
    // 初始化 Base成分
    Base::Base();
    // 试图构造dm1
    try  {  dm1.std::string::string();  }
    catch(...)  {
        // 如果抛出异常  销毁 base class成分，并传播该异常
        Base::~Base();
        throw;
    }
    // 试图构造dm2
    try  {  dm2.std::string::string();  }
    catch(...)  {
        // 如果抛出异常，销毁dm1  base class 成分，并传播异常
        dm1.std::string::~string();
        Base::~Base();
        throw;
    }
    // 试图构造dm3
    try  {  dm3.std::string::string();  }
    catch(...)  {
        // 如果抛出异常，销毁dm2，dm1，base class成分，并传播该异常
        dm2.std::string::~string();
        dm1.std::string::~string();
        Base::~Base();
        throw;
    }
}

这段代码并不能代表编译器真正能制造出来的代码，因为真正的编译器会以更精致复杂的做法来处理异常。

虽然如此，这也已经准确反映Derived的空白构造函数所必须提供的行为。

不论编译器在其内所做的异常处理多么精致复杂，Derived的构造函数至少一定会陆续调用其成员变量和base class两者的构造函数，而那些调用（它们自身也可能被inlined）会影响编译器是否对此空白函数inlining。

相同理由也适用于Base构造函数，所以如果它被inlined，所有替换“Base构造函数调用”而插入的代码也都会被插入到“Derived构造函数调用”内（因为Derived构造函数调用了Base构造函数）。

所以，程序库设计者必须评估“将函数声明为inline”的冲击；inline函数无法随着程序库的升级而升级。

若从纯粹实用的观点出发，有一个事实比其他因素更重要：大部分调试器面对inline函数都束手无策。

毕竟你没办法在一个并不存在的函数内设立断点。

4.总结

在决定哪些函数盖被声明为inline而哪些函数不该时，掌握一个合乎逻辑的策略

> 一开始先不要将任何函数声明为inline，或至少将inlining施行范围局限在那些”一定成为inline”或“十分平淡无奇”的函数身上。

> 慎重使用inline便是对日后使用调试器带来帮助，不过这么一来也等于把自己推向手工最优化的道路。

> 不要忘记 80-20 经验法则：平均一个程序往往将80%的执行时间花在20%的代码上头。所以，找出可以有效增进程序整体效率的20%代码，然后将它inline或接近所能地将它瘦身。BUT，首先你要选对目标！