ei33.htm

一个非常适合初学者入门的有关c++的文档

</UL>
<UL><PRE><A NAME="6773"></A>
  pf();                          // a non-inline call to f
                                 // through pf
  ...
}
</PRE>
</UL>

<A NAME="6774"></A>
<P><A NAME="dingp14"></A>
In this case, you end up in the seemingly paradoxical situation whereby calls to <CODE>f</CODE> are inlined, but &#151; under the old rules &#151; each translation unit that takes <CODE>f</CODE>'s address still generates a static copy of the function. (Under the new rules, only a single out-of-line copy of <CODE>f</CODE> will be generated, regardless of the number of translation units <NOBR>involved.)<SCRIPT>create_link(14);</SCRIPT>
</NOBR></P>
<A NAME="18604"></A>
<P><A NAME="dingp15"></A>
This aspect of un-inlined inline functions can affect you even if you never use function pointers, because programmers aren't necessarily the only ones asking for pointers to functions. Sometimes compilers do it. In particular, compilers sometimes generate out-of-line copies of constructors and destructors so that they can get pointers to those functions for use in constructing and destructing arrays of objects of a class (see also <A HREF="../MEC/MI8_FR.HTM#33985" TARGET="_top">Item M8</A>).<SCRIPT>create_link(15);</SCRIPT>
</P>
<A NAME="18603"></A>
<P><A NAME="dingp16"></A>
In fact, constructors and destructors are often worse candidates for inlining than a casual examination would indicate. For example, consider the constructor for class <CODE>Derived</CODE> <NOBR>below:<SCRIPT>create_link(16);</SCRIPT>
</NOBR></P><UL><PRE><A NAME="18641"></A>
class Base {
public:
  ...</PRE>
</UL>
<UL><PRE><A NAME="18642"></A>private:
  string bm1, bm2;	 	// base members 1 and 2
};</PRE>
</UL>
<UL><PRE><A NAME="18643"></A>class Derived: public Base {
public:
  Derived() {}                  // Derived's ctor is
  ...                           // empty -- or is it?
</PRE>
</UL>

<UL><PRE><A NAME="213492"></A><a name="p141"></a>
private:
  string dm1, dm2, dm3;         // derived members 1-3
};
</PRE>
</UL>

<A NAME="213494"></A>
<P><A NAME="dingp17"></A>
This constructor certainly looks like an excellent candidate for inlining, since it contains no code. But looks can be deceiving. Just because it contains no code doesn't necessarily mean it contains no code. In fact, it may contain a fair amount of <NOBR>code.<SCRIPT>create_link(17);</SCRIPT>
</NOBR></P>
<A NAME="18649"></A>
<P><A NAME="dingp18"></A>
C++ makes various guarantees about things that happen when objects are created and destroyed. Items <A HREF="./EI5_FR.HTM#1869" TARGET="_top">5</A> and <A HREF="../MEC/MI8_FR.HTM#33985" TARGET="_top">M8</A> describes how when you use <CODE>new</CODE>, your dynamically created objects are automatically initialized by their constructors, and how when you use <CODE>delete</CODE>, the corresponding destructors are invoked. <A HREF="./EI13_FR.HTM#2117" TARGET="_top">Item 13</A> explains that when you create an object, each base class of and each data member in that object is automatically constructed, and the reverse process regarding destruction automatically occurs when an object is destroyed. Those items describe what C++ says must happen, but C++ does not say <I>how</I> they happen. That's up to compiler implementers, but it should be clear that those things don't just happen by themselves. There has to be some code in your program to make those things happen, and that code &#151; the code written by compiler implementers and inserted into your program during compilation &#151; has to go somewhere. Sometimes, it ends up in your constructors and destructors, so some implementations will generate code equivalent to the following for the allegedly empty <CODE>Derived</CODE> constructor <NOBR>above:<SCRIPT>create_link(18);</SCRIPT>
</NOBR></P><UL><PRE><A NAME="18666"></A>// possible implementation of Derived constructor
 Derived::Derived()
{
  // allocate heap memory for this object if it's supposed
  // to be on the heap; see <A HREF="./EI8_FR.HTM#120851" TARGET="_top">Item 8</A> for info on operator new
  if (<I>this object is on the heap</I>)
    this = ::operator new(sizeof(Derived));
</PRE>
</UL><UL><PRE><A NAME="18667"></A><A NAME="18668"></A>
  Base::Base();                  // initialize Base part

  dm1.string();	 	         // construct dm1
  dm2.string();	 	         // construct dm2
  dm3.string();	 	         // construct dm3
}
</PRE>
</UL>

<A NAME="18672"></A>
<P><A NAME="dingp19"></A>
You could never hope to get code like this to compile, because it's not legal C++ &#151; not for you, anyway. For one thing, you have no way of asking whether an object is on the heap from inside its constructor. (For an examination of what it takes to reliably determine whether an object is on the heap, see <A HREF="../MEC/MI27_FR.HTM#22627" TARGET="_top">Item M27</A>.) For another, you're forbidden from assigning to <CODE>this</CODE>. And you can't invoke constructors via function calls, either. Your compilers, however, labor under no such constraints &#151; they can do whatever they like. But the legality of the code is not the point. The point is that code to call <a name="p142"></a><CODE>operator</CODE> <CODE>new</CODE> (if necessary), to construct base class parts, and to construct data members may be silently inserted into your constructors, and when it is, those constructors increase in size, thus making them less attractive candidates for inlining. Of course, the same reasoning applies to the <CODE>Base</CODE> constructor, so if it's inlined, all the code inserted into it is also inserted into the <CODE>Derived</CODE> constructor (via the <CODE>Derived</CODE> constructor's call to the <CODE>Base</CODE> constructor). And if the <CODE>string</CODE> constructor also happens to be inlined, the <CODE>Derived</CODE> constructor will gain <I>five copies</I> of that function's code, one for each of the five strings in a <CODE>Derived</CODE> object (the two it inherits plus the three it declares itself). Now do you see why it's not necessarily a no-brain decision whether to inline <CODE>Derived</CODE>'s constructor? Of course, similar considerations apply to <CODE>Derived</CODE>'s destructor, which, one way or another, must see to it that all the objects initialized by <CODE>Derived</CODE>'s constructor are properly destroyed. It may also need to free the dynamically allocated memory formerly occupied by the just-destroyed <CODE>Derived</CODE> <NOBR>object.<SCRIPT>create_link(19);</SCRIPT>
</NOBR></P>
<A NAME="6776"></A>
<P><A NAME="dingp20"></A>
Library designers must evaluate the impact of declaring functions <CODE>inline</CODE>, because inline functions make it impossible to provide binary upgrades to the inline functions in a library. In other words, if <CODE>f</CODE> is an inline function in a library, clients of the library compile the body of <CODE>f</CODE> into their applications. If a library implementer later decides to change <CODE>f</CODE>, all clients who've used <CODE>f</CODE> must recompile. This is often highly undesirable (see also <A HREF="./EI34_FR.HTM#6793" TARGET="_top">Item 34</A>). On the other hand, if <CODE>f</CODE> is a non-<CODE>inline</CODE> function, a modification to <CODE>f</CODE> requires only that clients relink. This is a substantially less onerous burden than recompiling and, if the library containing the function is dynamically linked, one that may be absorbed in a way that's completely transparent to <NOBR>clients.<SCRIPT>create_link(20);</SCRIPT>
</NOBR></P>
<A NAME="223401"></A>
<P><A NAME="dingp21"></A>
Static objects inside inline functions often exhibit counterintuitive behavior. For this reason, it's generally a good idea to avoid declaring functions <CODE>inline</CODE> if those functions contain static objects. For details, consult <A HREF="../MEC/MI26_FR.HTM#5350" TARGET="_top">Item M26</A>.<SCRIPT>create_link(21);</SCRIPT>
</P>
<A NAME="18637"></A>
<P><A NAME="dingp22"></A>
For purposes of program development, it is important to keep all these considerations in mind, but from a purely practical point of view during coding, one fact dominates all others: most debuggers have trouble with inline <NOBR>functions.<SCRIPT>create_link(22);</SCRIPT>
</NOBR></P>
<A NAME="6777"></A>
<P><A NAME="dingp23"></A>
This should be no great revelation. How do you set a breakpoint in a function that isn't there? How do you step through such a function? How do you trap calls to it? Without being unreasonably clever (or deviously underhanded), you simply can't. Happily, this leads to a logical strategy for determining which functions should be declared <CODE>inline</CODE> and which should <NOBR>not.<SCRIPT>create_link(23);</SCRIPT>
</NOBR></P>
<A NAME="6778"></A>
<P><A NAME="dingp24"></A>
Initially, don't inline anything, or at least limit your inlining to those functions that are truly trivial, such as <CODE>age</CODE> <NOBR>below:<SCRIPT>create_link(24);</SCRIPT>
</NOBR></P><UL><PRE><A NAME="6780"></A><a name="p143"></a>class Person {
public:
  int age() const { return personAge; }
<A NAME="6783"></A>
  ...
<A NAME="18615"></A>
private:
  int personAge;
<A NAME="18616"></A>
  ...
<A NAME="6784"></A>
};</PRE>
</UL>
<A NAME="6785"></A>
<P><A NAME="dingp25"></A>
By employing inlines cautiously, you facilitate your use of a debugger, but you also put inlining in its proper place: as a hand-applied optimization. Don't forget the empirically determined rule of 80-20 (see <A HREF="../MEC/MI16_FR.HTM#40995" TARGET="_top">Item M16</A>), which states that a typical program spends 80 percent of its time executing only 20 percent of its code. It's an important rule, because it reminds you that your goal as a software developer is to identify the 20 percent of your code that is actually capable of increasing your program's overall performance. You can inline and otherwise tweak your functions until the cows come home, but it's all wasted effort unless you're focusing on the <I>right</I> <NOBR>functions.<SCRIPT>create_link(25);</SCRIPT>
</NOBR></P>
<A NAME="6787"></A>
<P><A NAME="dingp26"></A>
Once you've identified the set of important functions in your application, the ones whose inlining will actually make a difference (a set that is itself dependent on the architecture on which you're running), don't hesitate to declare them <CODE>inline</CODE>. At the same time, however, be on the lookout for problems caused by code bloat, and watch out for compiler warnings (see <A HREF="./EI48_FR.HTM#8378" TARGET="_top">Item 48</A>) that indicate that your inline functions haven't been <NOBR>inlined.<SCRIPT>create_link(26);</SCRIPT>
</NOBR></P>
<A NAME="6791"></A>
<P><A NAME="dingp27"></A>
Used judiciously, inline functions are an invaluable component of every C++ programmer's toolbox, but, as the foregoing discussion has revealed, they're not quite as simple and straightforward as you might have <NOBR>thought.<SCRIPT>create_link(27);</SCRIPT>
</NOBR></P>

<DIV ALIGN="CENTER"><FONT SIZE="-1">Back to <A HREF="./EI32_FR.HTM" TARGET="_top">Item 32: Postpone variable definitions as long as possible.</A> &nbsp;&nbsp;<BR>&nbsp;&nbsp;Continue to <A HREF="./EI34_FR.HTM" TARGET="_top">Item 34: Minimize compilation dependencies between files.</A></FONT></DIV>

</BODY>
</HTML>