条款30:透彻了解inlining的里里外外

inlie函数背后整体观念是,将"对此函数的每一个调用"都以函数本体替换之Inlining在大多数C++程序中是编译行为大部分编译器拒绝将太过复杂(例如循环或递归)的函数inlining,而所有对virtual函数的调用也会使inlining落空,因为virtual意味着"等待,知道运行期才确定调用那个函数",而inling意味着"执行前,先将调用动作替换为被调用函数的本体";编译器通常不对"通过函数指针而进行的调用"实施inlining,这意味着对inline函数的调用有可能被inlined,也有可能不被inlined,如下代码: inine void f() {} // 假设编译器有意愿inline"对f的调用" void (* pf) () = f; // pf指向f //... f(); // 这个调用将被inlined,因为是一个正常调用 pf(); // 这个调用或许不被inlined,因为它通过函数指针达成 构造函数和析构函数往往是inlining的糟糕候选人,考虑如下代码 class Base { public: // ... private: std::string bm1, bm2; }; class Derived : public Base { public: Derived() {} // Derived构造函数是空的吗??? //... private: std::string dm1, dm2, dm3; };

Derived构造函数看起来是inlining的绝佳候选人,因为他根本不含任何代码,但是事实可以理解为如下:

Derived::Derived() { // "空白Derived构造函数"的观念性实现 Base::Base(); // 初始化Base成分 try { dm1.std::string::string();// 试图构造dm1 } catch (...) { Base::~Base(); // 如果抛出异常就销毁base class成分,并传播该异常 throw; } try { dm2.std::string::string();// 试图构造dm2 } catch (...) { dm1.std::string::~string();// 如果抛出异常就销毁dm1,销毁base class成分,并传播该异常 Base::~Base(); throw; } try { dm3.std::string::string();// 试图构造dm3 } catch (...) { dm2.std::string::~string(); // 如果抛出异常就销毁dm2,销毁dm1,销毁base class成分,并传播该异常 dm1.std::string::~string(); Base::~Base(); throw; } }

以上代码并不能代表编译器真正制造出来的代码,因为现实情况是编译器会以更精致的做法处理异常;Derived构造函数至少一定会陆续调用其成员变量和base class两者的构造函数,如果Base构造函数被inlined,所有替换"Base构造函数调用"而插入的代码也会被插入到"Derived构造函数调用"内;如果string构造函数恰巧也别inlined,则Derived构造函数将获得五份"string 构造函数代码"副本,每一份副本对应于Derived对象的五个字符串(两个来自继承,三个来自自己的声明)之一;

还有一个事实就是大部分调试器对inline函数都束手无策,因为你无法在一个并不存在的函数内打断点调试