inline void f() {...} // assume compilers are willing to inline calls to f5 m( |9 }) P, x# ^: R# [; Y. F6 A
& d8 t* `4 B0 V
void (*pf)() = f; // pf points to f# x5 ?9 D1 |! C+ _; ?2 t1 }
...
8 Q# s T$ r$ f- |/ t9 O) ^* V: F4 n0 {$ Q. P- s+ u0 e2 C! W
f(); // this call will be inlined, because it’s a "normal" call0 y* e5 [) p' a# e; g
pf(); // this call probably won’t be, because it’s through
6 A! D' m' q/ G+ B0 i5 Z/ {// a function pointer
/ g" R- \' V+ i: G 甚至在你从来没有使用函数指针的时候,未 inline 化的 inline 函数的幽灵也会时不时地拜访你,因为程序员并不必然是函数指针的唯一需求者。有时候编译器会生成构造函数和析构函数的 out-of-line 拷贝,以便它们能得到指向这些函数的指针,在对数组中的对象进行构造和析构时使用。
( F9 _) V! e& ^0 u' p
7 ^3 L m* Z$ M, ]) H 事实上,构造函数和析构函数对于 inline 化来说经常是一个比你在不经意的检查中所能显示出来的更加糟糕的候选者。例如,考虑下面这个类 Derived 的构造函数:
2 ?6 F" d2 ~2 w# G' i3 G" B: a! u9 j0 ?9 F. f
class Base {
" v- ?/ Q9 ]+ S4 L$ [% e public:
. Q* m h0 m. u' k0 c2 ~% ?$ v ... </p>
& x2 A: u' j3 Pprivate:; C8 I6 F& S0 Q4 T
std::string bm1, bm2; // base members 1 and 2
. m3 }4 ~& @5 L1 i2 W};6 X' t7 E" r5 C
% [* N$ P$ M: r$ z1 i8 l$ [1 B/ m
class Derived: public Base {
( z% i5 y. f! f9 f public:
4 @6 g/ }5 x8 r Derived() {} // Derived’s ctor is empty - or is it?, P# g( o- C2 C6 a
...
+ a- \* S" b! j4 x9 V
, c8 D/ B1 k. Z$ ]' Y8 p% y; q' ?1 r private:8 P3 n n* O* w. [4 @- ~) c" _5 d$ j
std::string dm1, dm2, dm3; // derived members 1-3) a' _4 M4 ?7 Z' K2 R
};
- s2 O8 P1 M( V, T2 P 这个构造函数看上去像一个 inline 化的极好的候选者,因为它不包含代码。但是视觉会被欺骗。
* H4 Y6 D/ C: Z4 ?5 K
6 p1 c, O" U' s+ j5 L C 为对象被创建和被销毁时所发生的事情做出了各种保证。例如,当你使用 new 时,你的动态的被创建对象会被它们的构造函数自动初始化,而当你使用 delete。则相应的析构函数会被调用。当你创建一个对象时,这个对象的每一个基类和每一个数据成员都会自动构造,而当一个对象被销毁时,则发生关于析构的反向过程。如果在一个对象构造期间有一个异常被抛出,这个对象已经完成构造的任何部分都被自动销毁。所有这些情节,C 只说什么必须发生,但没有说如何发生。那是编译器的实现者的事,但显然这些事情不会自己发生。在你的程序中必须有一些代码使这些事发生,而这些代码——由编译器写出的代码和在编译期间插入你的程序的代码——必须位于某处。有时它们最终就位于构造函数和析构函数中,所以我们可以设想实现为上面那个声称为空的 Derived 的构造函数生成的代码就相当于下面这样:
9 A- B, p; m4 ^7 w! ?
8 [3 P, Q/ m2 X7 h6 _& w# zDerived::Derived() // conceptual implementation of5 B( k4 q5 Z2 A
{ : B4 R0 p- k* l/ T
// "empty" Derived ctor! b4 I/ v1 h7 }, X1 H
( E8 A, C" G2 e3 D6 `$ X4 @' X( i Base::Base(); // initialize Base part
' U& a y, A6 R: q$ N( |& h1 }8 e$ c8 W
try { dm1.std::string::string(); } // try to construct dm1' F; w% E: G: p% g8 v
catch (...) { // if it throws,
3 |9 Q* r1 F/ F/ ?# j Base::~Base(); // destroy base class part and
3 L3 j; I+ {5 T- |4 T+ s throw; // propagate the exception
" l9 F7 r2 t# f h" C}: c# v* l& K6 e% S, Q
" p5 v3 t9 `, C& a+ g) O5 {6 U
try { dm2.std::string::string(); } // try to construct dm2
/ L. m" }7 I! v, t+ Ycatch(...) {
0 Y3 M( {8 o; z // if it throws," Y# O# b* B& Z9 L) b* F% \
dm1.std::string::~string(); // destroy dm1,) k' U$ t4 h& l
Base::~Base(); // destroy base class part, and
" a' X6 K; J" Q/ u. Y6 K& @throw; // propagate the exception
_5 F1 \+ Z$ d* }8 ?* q}. x- m" o( a ]4 n5 a" C# U9 L- _
' g& w8 P" K% x7 c& Ntry { dm3.std::string::string(); } // construct dm3
# F9 z, D6 f: G+ kcatch(...) { 3 s& G4 w2 e2 E: c- r- V, B K3 P
// if it throws,* s6 a2 ]: g0 g, G6 J/ p% ?
dm2.std::string::~string(); // destroy dm2,% v4 E9 B: n3 P& A, S) o
dm1.std::string::~string(); // destroy dm1,
1 D) Y# j% [1 @* D# f Base::~Base(); // destroy base class part, and3 r/ d% D& Q. h" Y! _2 c
throw; // propagate the exception
6 d" l# |$ x. p}
* |# {+ J2 _' Y; P) ]}
/ S( n' M1 X" w; X6 H
h5 {- q& t5 K0 B/ w/ G9 M+ A! }- b% I) f
这些代码并不代表真正的编译器所生成的,因为真正的编译器会用更复杂的方法处理异常。尽管如此,它还是准确地反映了 Derived 的“空”构造函数必须提供的行为。不论一个编译器的异常多么复杂,Derived 的构造函数至少必须调用它的数据成员和基类的构造函数,而这些调用(它们自己也可能是 inline 的)会影响它对于 inline 化的吸引力。
+ T" o2 c2 q. m7 G+ [, ^( o, ]( d7 q- R
同样的原因也适用于 Base 的构造函数,所以如果它是 inline 的,插入它的全部代码也要插入 Derived 的构造函数(通过 Derived 的构造函数对 Base 的构造函数的调用)。而且如果 string 的构造函数碰巧也是 inline 的,Derived 的构造函数中将增加五个那个函数代码的拷贝,分别对应于 Derived 对象中的五个 strings(两个继承的加上三个它自己声明的)。也许在现在,为什么说是否 inline 化 Derived 的构造函数不是一个不经大脑的决定就很清楚了。类似的考虑也适用于 Derived 的析构函数,用同样的或者不同的方法,必须保证所有被 Derived 的构造函数初始化的对象被完全销毁。" Y& L# ~ [0 k( f* c0 r
; c& U6 ?- h9 x& N/ a( k$ I4 T; E
库设计者必须评估声明函数为 inline 的影响,因为为库中的客户可见的 inline 函数提供二进制升级版本是不可能的。换句话说,如果 f 是一个库中的一个 inline 函数,库的客户将函数 f 的本体编译到他们的应用程序中。如果一个库的实现者后来决定修改 f,所有使用了 f 的客户都必须重新编译。这常常会令人厌烦。在另一方面,如果 f 是一个非 inline 函数,对 f 的改变只需要客户重新连接。这与重新编译相比显然减轻了很大的负担,而且,如果库中包含的函数是动态链接的,这就是一种对于用户来说完全透明的方法。 Z+ O8 p$ G" F. g& q# e
: x$ K( [( C3 o" C( { 为了程序开发的目标,在头脑中牢记这些需要考虑的事项是很重要的,但是从编码期间的实用观点来看,占有支配地位的事实是:大多数调试器会与 inline 函数发生冲突。这不应该是什么重大的发现。你怎么能在一个不在那里的函数中设置断点呢?虽然一些构建环境设法支持 inline 函数的调试,多数环境还是简单地为调试构建取消了 inline 化。 |