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(来自)往往这样实现:
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,首先你要选对目标!
☆ 请记住 ☆
▪ 将大多数inlining限制在小型、被频繁调用的函数身上。这可使日后的调试过程和二进制升级更容易,也可潜在的代码膨胀问题最小化,使程序的速度提升机会最大化。
▪ 不要只因为 function templates 出现在头文件,就将它们声明为inline。