inlining的里里外外

最近在看Effective C++，有些关于inline的摘录下来以供大家理解。

Inline 函数通常一定被置于头文件中，因为大多数建置环境在编译过程中进行inlining，而为了讲一个函数调用替换与被调用函数的本体，编译器必须知道那个函数长成什么样子。Inlinling在大多数C++程序中都是编译期行为。

程序设计者必须评估“将函数声明为Inline”的冲击：inline函数无法随着程序库的升级而升级。换句话说如果f是程序库内的一个inline函数，客户将“f函数本体”编译其程序中，一单程序库设计者决定改变f，所有用到f的客户端程序都必须重新编译。这往往是大家不愿意看到的。然而如果f是non-inline函数，一旦它有任何修改，客户端只需要重新连接就好，远比重新编译的负担少很多。如果程序库采取动态连接，升级版函数甚至可以不知不觉被应用程序心爱。

对程序开发而言，有个事实比其他因素更重要：大部分调试器面对Inline函数都束手无策。这个对于你应该不是太大的意外，毕竟你如何在一个并不存在的函数内设立断点？虽然某些建置环境勉力支持对inlined函数的调试，其他许多建置环境仅仅只能在调试版程序中禁止发生inlining。

将对多数inlinling函数建置在小型，被频繁嗲用的函数身上，这可使得日后的调试过程和二进制升级更为容易，也可使得代码膨胀问题最小化，使得程序的速度提升机会更大化。

不要只因为function templates出现在头文件，就将他们声明成inline