ec5.htm

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

</NOBR></P>
<A NAME="6737"></A>
<P><A NAME="dingp89"></A>
However, let's not get carried away. In programming, as in life, there is no free lunch, and inline functions are no exception. The whole idea behind an inline function is to replace each call of that function with its code body, and it doesn't take a Ph.D. in statistics to see that this is likely to increase the overall size of your object code. On machines with limited memory, overzealous inlining can give rise to programs that are too big for the available space. Even with virtual memory, inline-induced code bloat can lead to pathological paging behavior (thrashing) that will slow your program to a crawl. (It will, however, provide your disk controller with a nice exercise regimen.) Too much inlining can also reduce your instruction cache hit rate, thus reducing <A NAME="p138"></A>the speed of instruction fetch from that of cache memory to that of primary <NOBR>memory.<SCRIPT>create_link(89);</SCRIPT>
</NOBR></P>
<A NAME="6739"></A>
<P><A NAME="dingp90"></A>
On the other hand, if an inline function body is <I>very</I> short, the code generated for the function body may actually be smaller than the code generated for a function call. If that is the case, inlining the function may actually lead to <I>smaller</I> object code and a higher cache hit <NOBR>rate!<SCRIPT>create_link(90);</SCRIPT>
</NOBR></P>
<A NAME="6741"></A>
<P><A NAME="dingp91"></A>
Bear in mind that the <CODE>inline</CODE> directive, like <CODE>register</CODE>, is a <I>hint</I> to compilers, not a command. That means compilers are free to ignore your inline directives whenever they want to, and it's not that hard to make them want to. For example, most compilers refuse to inline "complicated" functions (e.g., those that contain loops or are recursive), and all but the most trivial virtual function calls stop inlining routines dead in their tracks. (This shouldn't be much of a surprise. <CODE>virtual</CODE> means "wait until runtime to figure out which function to call," and <CODE>inline</CODE> means "during compilation, replace the call site with the called function." If compilers don't know which function will be called, you can hardly blame them for refusing to make an inline call to it.) It all adds up to this: whether a given inline function is actually inlined is dependent on the implementation of the compiler you're using. Fortunately, most compilers have a diagnostic level that will result in a warning (see <A HREF="./EC7_FR.HTM#8378" TARGET="_top">Item 48</A>) if they fail to inline a function you've asked them <NOBR>to.<SCRIPT>create_link(91);</SCRIPT>
</NOBR></P>
<A NAME="6750"></A>
<P><A NAME="dingp92"></A>
Suppose you've written some function <CODE>f</CODE> and you've declared it <CODE>inline</CODE>. What happens if a compiler chooses, for whatever reason, not to inline that function? The obvious answer is that <CODE>f</CODE> will be treated like a non-inline function: code for <CODE>f</CODE> will be generated as if it were a normal "outlined" function, and calls to <CODE>f</CODE> will proceed as normal function <NOBR>calls.<SCRIPT>create_link(92);</SCRIPT>
</NOBR></P>
<A NAME="18543"></A>
<P><A NAME="dingp93"></A>
In theory, this is precisely what will happen, but this is one of those occasions when theory and practice may go their separate ways. That's because this very tidy solution to the problem of what to do about "outlined inlines" was added to C++ relatively late in the standardization process. Earlier specifications for the language (such as the ARM &#151; see <A HREF="./EC7_FR.HTM#8569" TARGET="_top">Item 50</A>) told compiler vendors to implement different behavior, and the older behavior is still common enough that you need to understand what it <NOBR>is.<SCRIPT>create_link(93);</SCRIPT>
</NOBR></P>
<A NAME="6751"></A>
<P><A NAME="dingp94"></A>
Think about it for a minute, and you'll realize that inline function definitions are virtually always put in header files. This allows multiple translation units (source files) to include the same header files and reap the advantages of the inline functions that are defined within them. Here's an example, in which I adopt the convention that source files end in ".cpp"; this is probably the most prevalent of the file naming conventions in the world of <NOBR>C++:<SCRIPT>create_link(94);</SCRIPT>
</NOBR></P>
<A NAME="p139"></A>
<UL><PRE><A NAME="6755"></A>
 // This is file example.h
 inline void f() { ... }	 	        // definition of f
</PRE>
</UL>
<UL><PRE><A NAME="6756"></A>
 ...
</PRE>
</UL>
<A NAME="6757"></A>
<UL><PRE><A NAME="6758"></A>
 // This is file source1.cpp
 #include "example.h"	 	 	 // includes definition of f
 	 	 	                    // contains calls to f</PRE>
</UL>
<UL><PRE><A NAME="6759"></A>
 ...
</PRE>
</UL>
<A NAME="6760"></A>
<UL><PRE><A NAME="6761"></A>
 // This is file source2.cpp
 #include "example.h"	 	 	 // also includes definition
	                   	 	 	 // of f
						 // also calls f
 ...
</PRE>
</UL>
<UL><PRE><A NAME="19386"></A>

</PRE>
</UL>
<A NAME="6762"></A>
<P><A NAME="dingp95"></A>
Under the old "outlined inline" rules and the assumption that <CODE>f</CODE> is <I>not</I> being inlined, when <CODE>source1.cpp</CODE> is compiled, the resulting object file will contain a function called <CODE>f</CODE>, just as if <CODE>f</CODE> had never been declared <CODE>inline</CODE>. Similarly, when <CODE>source2.cpp</CODE> is compiled, its generated object file will also hold a function called <CODE>f</CODE>. When you try to link the two object files together, you can reasonably expect your linker to complain that your program contains two definitions of <CODE>f</CODE>, an <NOBR>error.<SCRIPT>create_link(95);</SCRIPT>
</NOBR></P>
<A NAME="6764"></A>
<P><A NAME="dingp96"></A>
To prevent this problem, the old rules decreed that compilers treat an un-inlined inline function as if the function had been declared <CODE>static</CODE> &#151; that is, local to the file currently being compiled. In the example you just saw, compilers following the old rules would treat <CODE>f</CODE> as if it were static in <CODE>source1.cpp</CODE> when that file was being compiled and as if it were static in <CODE>source2.cpp</CODE> when that file was being compiled. This strategy eliminates the link-time problem, but at a cost: each translation unit that includes the definition of <CODE>f</CODE> (and that calls <CODE>f</CODE>) contains its own static copy of <CODE>f</CODE>. If <CODE>f</CODE> itself defines local static variables, each copy of <CODE>f</CODE> gets its <I>own copy</I> of the variables, something sure to astonish programmers who believe that "<CODE>static</CODE>" inside a function means "only one <NOBR>copy."<SCRIPT>create_link(96);</SCRIPT>
</NOBR></P>
<A NAME="6766"></A>
<P><A NAME="dingp97"></A>
This leads to a stunning realization. Under both new rules and old, if an inline function isn't inlined, you <I>still</I> pay for the cost of a function call at each call site, but under the old rules, you can <I>also</I> suffer an increase in code size, because each translation unit that includes and calls <CODE>f</CODE> gets its own copy of <CODE>f</CODE>'s code and <CODE>f</CODE>'s static variables! (To make matters worse, each copy of <CODE>f</CODE> and each copy of <CODE>f</CODE>'s static variables tend to end up on different virtual memory pages, so two calls to different copies of <CODE>f</CODE> are likely to entail one or more page <NOBR>faults.)<SCRIPT>create_link(97);</SCRIPT>
</NOBR></P>
<A NAME="6768"></A>
<P><A NAME="dingp98"></A>
<A NAME="p140"></A>There's more. Sometimes your poor, embattled compilers have to generate a function body for an inline function even when they are perfectly willing to inline the function. In particular, if your program ever takes the address of an inline function, compilers must generate a function body for it. How can they come up with a pointer to a function that doesn't <NOBR>exist?<SCRIPT>create_link(98);</SCRIPT>
</NOBR></P><UL><PRE><A NAME="6770"></A>
inline void f() {...}            // as above
</PRE>
</UL>

<UL><PRE><A NAME="6771"></A>
void (*pf)() = f;                // pf points to f
</PRE>
</UL>

<UL><PRE><A NAME="6772"></A>
int main()
{
  f();                           // an inline call to f
</PRE>
</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="dingp99"></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(99);</SCRIPT>
</NOBR></P>
<A NAME="18604"></A>
<P><A NAME="dingp100"></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/MC2_FR.HTM#33985" TARGET="_top">Item M8</A>).<SCRIPT>create_link(100);</SCRIPT>
</P>
<A NAME="18603"></A>
<P><A NAME="dingp101"></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(101);</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="dingp102"></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(102);</SCRIPT>
</NOBR></P>
<A NAME="18649"></A>
<P><A NAME="dingp103"></A>
C++ makes various guarantees about things that happen when objects are created and destroyed. Items <A HREF="./EC2_FR.HTM#1869" TARGET="_top">5</A> and <A HREF="../MEC/MC2_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="./EC3_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(103);</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="./EC2_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="dingp104"></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/MC5_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(104);</SCRIPT>
</NOBR></P>
<A NAME="6776"></A>
<P><A NAME="dingp105"></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="#6793">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(105);</SCRIPT>
</NOBR></P>
<A NAME="223401"></A>
<P><A NAME="dingp106"></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/MC5_FR.HTM#5350" TARGET="_top">Item M26</A>.<SCRIPT>create_link(106);</SCRIPT>
</P>
<A NAME="18637"></A>
<P><A NAME="dingp107"></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(107);</SCRIPT>
</NOBR></P>
<A NAME="6777"></A>
<P><A NAME="dingp108"></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(108);</SCRIPT>
</NOBR></P>
<A NAME="6778"></A>
<P><A NAME="dingp109"></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(109);</SCRIPT>
</NOBR></P>
<A NAME="p143"></A>
<UL><PRE><A NAME="6780"></A>class Person {
public:
  int age() const { return personAge; }
<A NAME="6783"></A>
  ...
<A NAME="18615"></A>
private:
  int personAge;
<A NA