2012年计算机二级C语言基础：理解inline化的介入和排除

会计考友

　inline 函数——何等棒的主意啊！它们看起来像函数，它们发生的效不美观也像函数，它们在各方面都比宏好得太多太多，而你却可以在挪用它们时不招致函数挪用的成本。你还有什么更多的要求呢？
* o" T6 {9 L; R) f: {8 m% v
　　现实橄溷获得的可能比你想的更多，因为避免函数挪用的成本只是故事的一部门。在典型情形下，编译器的优化是为了一段持续的没有函数挪用的代码设计的，所以当你 inline 化一个函数，你可能就使得编译器能够对函数体实施上下文相关的非凡优化。大大都编译器都不会对 "outlined" 函数挪用实施这样的优化。

6 J, q; N) a" k0 z　　然而，在编程中，就像在糊口中，没有免费午餐，而 inline 函数也不破例。一个 inline 函数背后的思惟是用函数本体庖代每一处对这个函数的挪用，而且不必拿着统计表中的 Ph.D. 就可以看出这样可能会增添你的方针代码的巨细。在有限内存的机械上，过度热衷于 inline 化会使得轨范对于可用空间来说过于复杂。即使使用了虚拟内存，inline 引起的代码膨胀也会导致附加的分页调剂，削减指令缓存射中率，以及随之而来的机能损失踪。

3 p, D% g2 n& T! k; g　　在另一方面，如不美观一个 inline 函数本体很短，为函数本体生成的代码可能比为一个函数挪用生成的代码还要小。如不美观是这种情形，inline 化这个函数可以现实上导致更小的方针代码和更高的指令缓存射中率！ 记住，inline 是向编译器发出的一个请求，而不是一个呼吁。这个请求能够以显式的或隐式的体例提出。隐式的体例就是在一个类界说的内部界说一个函数：
& M1 E' @" `: n1 k( l% J
2 N2 n7 W6 w" z- x# _# K% Gclass Person {
　public:
) h: j4 \. I3 l　　...
3 w$ z" e3 y/ w) J' ?7 t6 f5 E　　int age() const { return theAge; } // an implicit inline request: age is
　　... // defined in a class definition
. w* E) _8 ~( w
　private:
　　int theAge;
8 [0 z5 t- [% z3 w: O7 g: y1 B};
　　这样的函数凡是是成员函数，不外我们知道友元函数也能被界耸ё仝类的内部，如不美观它们在那儿那里，它们也被隐式地声明为 inline。
8 Z2 R5 a- |3 h* r2 S; [
6 Q: Y/ |9 c- R, ~! A) c8 ?　　显式的声明一个 inline 函数的体例是在它的声明之前加上 inline 关头字。例如，以下就是尺度 max 模板（来自 ）经常用到的的实现体例：

  Z& d/ i6 S" p+ j, N. ^0 Jtemplate // an explicit inline
inline const T& std::max(const T& a, const T& b) // request: std::max is
{ return a < b ? b : a; } // preceded by "inline"
　　max 是一个模板的事实引出一个不雅察看结论：inline 函数和模板一般都是界耸ё仝头文件中的。这就使得一些轨范员得出结论断定函数模板必需是 inline。这个结论是犯警的而且有潜在的风险，所以它值得我们考绩一下。 inline 函数一般必需在头文件内，因为大大都构建情形在编译时代进行 inline 化。为了用被挪用函数的函数本体替代一个函数挪用，编译器必需知道函数看起来像什么样子。（有一些构建情形可以在毗连时代进行 inline 化，还有少数几个——好比，基于 .NET Common Language Infrastructure (CLI) 的节制情形——居然能在运行时 inline 化。然而，这些情形都是破例，并非轨则。inline 化在大大都 C 轨范中是一个编译时行为。）
- Z7 b! w, \% u+ |
　　模板一般在头文件内，因为编译器需要知道一个模板看起来像什么以便用到它时对它进行实例化。（同样，也不是全数如斯。一些构建情形可以在毗连时代进行模板实例化。然而，编译期实例化更为普遍。） 模板实例化与 inline 化无关。如不美观你写了一个模板，而且你认为所有从这个模板实例化出来的函数都应该是 inline 的，那么就声明这个模板为 inline，这就是膳缦沔的 std::max 的实现被做的工作。可是如不美观你为没有理由要 inline 化的函数写了一个模板，就要避免声明这个模板为 inline（无论显式的仍是隐式的）。inline 化是佣旧本的，而且你不但愿在毫无预见的情形下遭遇它们。我们已经说到 inline 化是若何引起代码膨胀的，可是，还有其它的成本，过一会儿我们再谈判。
! b$ i8 U5 H& B  m3 g* ^4 y
  g5 w# z0 u( M  f% Z　　在做这件事之前，我们先来完核对这个结论的考绩：inline 是一个编译器可能忽略的请求。大大都编译器拒绝它们认为太复杂的 inline 函数（例如，那些包含轮回或者递归的），而且，除了最细碎的以外的全数虚拟函数的挪用都不会被 inline 化。不应该对这后一个结论感应惊奇。虚拟意味着“期待，直到运行时才能断定哪一个函数被挪用”，而 inline 意味着“执行之前，用被挪用函数庖代挪用的处所”。如不美观编译器不知道哪一个函数将被挪用，你很难求全它们拒绝 inline 化这个函数本体。
& j/ q* n+ `1 N. l
: i/ Q( q3 N% V# s9 v' y# L　　所有这些加在一路，得出：一个被指定的 inline 函数是否能真的被 inline 化，取决于你所使用的构建情形——主若是编译器。幸运的是，大大都编译器都有一个诊断条理，在它们不能 inline 化一个你提出的函数时，会导致矣闽警告。
　　有时辰，即使当编译器完全心甘情愿地 inline 化一个函数，他们仍是会为这个 inline 函数生成函数本体。例如，如不美观你的轨范要持有一个 inline 函数的地址，编译器必需为它生成一个 outlined 函数本体。他们怎么能生成一个指向根柢不存在的函数的指针呢？再加上，编译器一般不会对经由过程函数指针的挪用进行 inline 化，这就意味着，对一个 inline 函数的挪用可能被也可能不被 inline 化，依靠于这个挪用是若何做成的。