9192.htm

C++细节解释

<P>还有呢！有时，可怜的随时准备为您效劳的编译器即使很想内联一个函数，却不得不为这个内联函数生成一个函数体。特别是，如果程序中要取一个内联函数的地址，编译器就必须为此生成一个函数体。编译器怎么能产生一个指向不存在的函数的指针呢？</P> 
<P><BR>inline void f() {...}&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // 同上</P> 
<P>void (*pf)() = f;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // pf指向f</P> 
<P>int main()<BR>{<BR>&nbsp; f();&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // 对f的内联调用</P> 
<P>&nbsp; pf();&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // 通过pf对f的非内联调用<BR>&nbsp; ...<BR>}</P> 
<P>这种情况似乎很荒谬：f的调用被内联了，但在旧的规则下，每个取f地址的被编译单元还是各自生成了此函数的静态拷贝。（新规则下，不管涉及的被编译单元有多少，将只生成唯一一个f的外部拷贝）</P> 
<P>即使你从来不使用函数指针，这类"没被内联的内联函数"也会找上你的门，因为不只是程序员会使用函数指针，有时编译器也这么做。特别是，编译器有时会生成构造函数和析构函数的外部拷贝，这样就可以通过得到那些函数的指针，方便地构造和析构类的对象数组（参见条款M8）。</P> 
<P>实际上，随便一个测试就可以证明构造函数和析构函数常常不适合内联；甚至，情况比测试结果还糟。例如，看下面这个类Derived的构造函数：</P> 
<P><BR>class Base {<BR>public:<BR>&nbsp; ...<BR>private:<BR>&nbsp; string bm1, bm2;&nbsp; &nbsp;// 基类成员1和2<BR>};<BR>class Derived: public Base {<BR>public:<BR>&nbsp; Derived() {}&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // Derived的构造函数是空的，<BR>&nbsp; ...&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // ------但，真的是空的吗？</P> 
<P><BR>private:<BR>&nbsp; string dm1, dm2, dm3;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // 派生类成员1-3<BR>};</P> 
<P>这个构造函数看起来的确象个内联的好材料，因为它没有代码。但外表常常欺骗人！仅仅因为它没有代码并不能说明它真的不含代码。实际上，它含有相当多的代码。</P> 
<P>C++就对象创建和销毁时发生的事件有多方面的规定。条款5和M8介绍了当使用new时，动态创建的对象怎样自动地被它们的构造函数初始化，以及当使用delete时析构函数怎样被调用。条款13说明了当创建一个对象时，对象的每个基类以及对象的每个数据成员会被自动地创建；当对象被销毁时，会自动地执行相反的过程（即析构）。这些条款告诉你，C++规定了哪些必须发生，但没规定"怎么"发生。"怎么发生"取决于编译器的实现者，但要弄清楚的是，这些事件不是凭空自己发生的。程序中必然有什么代码使得它们发生，特别是那些由编译器的实现者写的、在编译其间插入到你的程序中的代码，必然也藏身于某个地方------有时，它们就藏身于你的构造函数和析构函数。所以，对于上面那个号称为空的Derived的构造函数，有些编译器会为它产生相当于下面的代码：</P> 
<P>// 一个Derived构造函数的可能的实现<BR>&nbsp;Derived::Derived()<BR>{<BR>&nbsp; // 如果在堆上创建对象，为其分配堆内存；<BR>&nbsp; // operator new的介绍参见条款8<BR>&nbsp; if (本对象在堆上)<BR>&nbsp;&nbsp;&nbsp; this = ::operator new(sizeof(Derived));</P> 
<P><BR>&nbsp; Base::Base();&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // 初始化Base部分</P> 
<P>&nbsp; dm1.string();&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // 构造dm1<BR>&nbsp; dm2.string();&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // 构造dm2<BR>&nbsp; dm3.string();&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // 构造dm3<BR>}</P> 
<P>别指望上面这样的代码可以通过编译，因为它在C++中是不合法的。首先，在构造函数内无法知道对象是不是在堆上。（想知道如何可靠地确定一个对象是否在堆上，请参见条款M27）另外，对this赋值是非法的。还有，通过函数调用访问构造函数也是不允许的。然而，编译器工作起来没这些限制，它可以随心所欲。但代码的合法性不是现在要讨论的主题。问题的要点在于，调用operator new（如果需要的话）的代码、构造基类部分的代码、构造数据成员的代码都会神不知鬼不觉地添加到你的构造函数中，从而增加构造函数的体积，使得构造函数不再适合内联。当然，同样的分析也适用于Base的构造函数，如果Base的构造函数被内联，添加到它里面的所有代码也会被添加到Derived的构造函数（Derived的构造函数会调用Base的构造函数）。如果string的构造函数恰巧也被内联，Derived的构造函数将得到其代码的5个拷贝，每个拷贝对应于Derived对象中5个string中的一个（2个继承而来，3个自己声明）。现在你应该明白，内联Derived的构造函数并非可以很简单就决定的！当然，类似的情况也适用于Derived的析构函数，无论如何都要清楚这一点：被Derived的构造函数初始化的所有对象都要被完全销毁。刚被销毁的对象以前可能占用了动态分配的内存，那么这些内存还需要释放。</P> 
<P>程序库的设计者必须预先估计到声明内联函数带来的负面影响。因为想对程序库中的内联函数进行二进制代码升级是不可能的。换句话说，如果f是库中的一个内联函数，用户会将f的函数体编译到自己的程序中。如果程序库的设计者后来要修改f，所有使用f的用户程序必须重新编译。这会很令人讨厌（参见条款34）。相反，如果f是非内联函数，对f的修改仅需要用户重新链接，这就比需要重新编译大大减轻了负担；如果包含这个函数的程序库是被动态链接的，程序库的修改对用户来说完全是透明的。</P> 
<P>内联函数中的静态对象常常表现出违反直觉的行为。所以，如果函数中包含静态对象，通常要避免将它声明为内联函数。具体介绍参见条款M26。</P> 
<P>为了提高程序开发质量，以上诸项一定要牢记在心。但在具体编程时，从纯实际的角度来看，有一个事实比其余的因素都重要：大多数调试器遇上内联函数都会无能为力。</P> 
<P>这不是什么新鲜事。你想，怎么在一个不存在的函数里设置断点呢？怎么单步执行到这样一个函数呢？怎么俘获对它的调用呢？除非你是个百年一遇的怪才，或者用了暗渡陈仓之类的伎俩，否则是不可能做到的。让人高兴的是，这一点倒是可以作为决定该不该对函数声明inline的决策依据之一。</P> 
<P>一般来说，实际编程时最初的原则是不要内联任何函数，除非函数确实很小很简单，象下面这个age函数：</P> 
<P>class Person {<BR>public:<BR>&nbsp; int age() const { return personAge; }</P> 
<P>&nbsp; ...</P> 
<P>private:<BR>&nbsp; int personAge;</P> 
<P>&nbsp; ...</P> 
<P>};</P> 
<P>慎重地使用内联，不但给了调试器更多发挥作用的机会，还将内联的作用定位到了正确的位置：它是一个根据需要而使用的优化工具。不要忘了从无数经验得到的这条80-20定律（参见条款M16）：一个程序往往花80%的时间来执行程序中20%的代码。这是一条很重要的定律，因为它提醒你，作为程序员的一个很重要的目标，就是找出这20%能够真正提高整个程序性能的代码。你可以选择内联你的函数，或者没必要就不内联，但这些选择只有作用在"正确"的函数上才有意义。</P> 
<P>一旦找出了程序中那些重要的函数，以及那些内联后可以确实提高程序性能的函数（这些函数本身依赖于所在系统的体系结构），就要毫不犹豫地声明为inline。同时，要注意代码膨胀带来的问题，并监视编译器的警告信息（参见条款48），看看是否有内联函数没有被编译器内联。</P> 
<P>若能做到明智地使用，内联函数将是每个C++程序员百宝箱中的一件无价之宝。当然，正如前面的讨论所揭示的，它们并不象所想象的那样简单和直接。<br> 
</P> 
</DIV></div></div> 
 
</center></BODY></HTML>