C + + inline functions

(i) inline function (excerpt from the third edition of C + + primer)

Adding the keyword inline to the function declaration or definition in the function return type specifies the min () as inline.

inline int min (int first, int secend) {/****/};

The inline function must be visible to the compiler so that it can expand the function within the point of the call. Unlike a non-inline function, the inline function must be defined in each text file that invokes the function . Of course, for different files of the same program, if the inline function appears, its definition must be the same . For compute of two files. C and DRAW.C program, programmers can not define such a min () function, it is in the compute. C Middle finger one thing while in draw. C Middle finger another thing. If the two definitions are not identical, the program will have undefined behavior:

to ensure that this does not happen, it is recommended that the definition of the inline function be placed in the header file . Include the header file in each file that invokes the inline function. This approach guarantees that there is only one definition for each inline function, and the programmer does not need to copy the code, and it is not possible to cause unintended mismatches during the lifetime of the program.

(ii) The programming style of the inline function (excerpted from the high Quality C++/C Programming Guide)

The keyword inline must be placed with the function definition body in order for the function to be inline, and only the inline is placed before the function declaration .

The following style of function Foo cannot be an inline function:

inline void Foo (int x, int y); Inline is only placed with function declarations

void Foo (int x, int y) {}

The following style of function foo becomes an inline function:

void Foo (int x, int y);

inline void Foo (int x, int y)//inline is placed with function definition body {}

So, inline is a "keyword for implementation", not a "keyword for declaration." In general, the user can read the declaration of a function, but cannot see the definition of the function. Although the inline keyword is prepended to the declaration and definition of inline functions in most textbooks, I don't think inline should appear in the declaration of a function. While this detail does not affect function functionality, it embodies a fundamental tenet of high quality C++/C program design: declarations and definitions are not to be confused, and the user does not need to know whether the function needs to be inline.

member functions defined in the class declaration will automatically become inline functions

For example

Class A

{

Public:void Foo (int x, int y) {}//automatically becomes an inline function

}

It is not a good programming style to place the definition of a member function in a class declaration, although it can bring about convenience in writing, but it should be changed to the following example:

Header file

Class A

{

Public

void Foo (int x, int y);

}

Definition file

inline void A::foo (int x, int y) {}

Using inline with caution

Inline can improve the efficiency of function execution, why not all functions are defined as inline functions? If all functions are inline functions, is it useful to "inline" the keyword? Inline is at the expense of code bloat (replication), which simply eliminates the overhead of function calls and thus increases the efficiency of function execution. If the time of executing the code in the function body is greater than the cost of the function call, then the efficiency will be harvested very little. On the other hand, the invocation of each inline function is to copy code, which increases the total code size of the program and consumes more memory space.

It is not advisable to use inline in the following situations:

(1) If the code in the function body is longer, using inline will result in a high cost of memory consumption.

(2) If there is a loop in the function body, the time to execute the function body code is greater than the cost of the function call. The constructors and destructors of a class are easily misunderstood to be more efficient for inline use. Be aware that constructors and destructors may hide behaviors such as "secretly" executing constructors and destructors for base or member objects. So don't arbitrarily place the definitions of constructors and destructors in class declarations. A good compiler will automatically cancel the unworthy inline based on the body of the function definition (this further illustrates that inline should not appear in the declaration of the function).

Note the point:

Inline functions can eliminate the efficiency burden of function calls and preserve the advantages of general functions. However, the inline function is not a panacea, and in some cases it can even reduce the performance of the program. So be cautious when you use it.
1. Let's take a look at the benefits of the inline function: from a user's point of view, the inline function looks like a normal function, it can have parameters and return values, it can have its own scope, but it does not introduce the burden of general function calls. In addition, it can be more secure and easier to debug than macros.
Of course, it should be realized that inline specifier is only a suggestion to the compiler, and the compiler has the right to ignore this suggestion. So how does the compiler decide whether the function is inline or not? In general, the key factors include the size of the function body, whether the local object is declared, the complexity of the function, and so on.
2. So what happens if a function is declared inline but not inline? Theoretically, when the compiler refuses to inline a function, that function is treated like a normal function, but there are some other problems. For example, the following code:
FileName Time.h
#include <ctime>
#include <iostream>
using namespace Std;
Class time
{
Public
inline void Show ()

{
for (int i = 0;   i<10; i++)
Cout<<time (0) <<endl;
}
};
Because the member function Time::show () includes a local variable and a for loop, the compiler generally rejects inline and treats it as a normal member function. However, the header file containing the class declaration is individually included in the individual compilation units:
FileName F1.cpp
#include "Time.h"
void F1 ()
{
Time T1;
T1. Show ();
}
FileName F2.cpp
#include "Time.h"
void F2 ()
{
Time T2;
T2. Show ();
}
The result compiler generates two copies of the same member function for this program:
void F1 ();
void F2 ();
int main ()
{
F1 ();
F2 ();
return 0;
}
When the program is linked, the linker will face two identical time::show () copies, and the function-redefined connection error occurs. But the older C + + implementations deal with this situation by treating a un-inlined function as static. Therefore, each copy of the function is visible only in its own compilation unit, so that the link error is resolved, but the program will leave a number of copies of the function. In this case, the performance of the program does not improve, but increases the compile and link time and the size of the final executable body. Fortunately, however, the new C + + Standard's argument about un-inlined functions has changed. A conforming standard C + + implementation should generate only one copy of the function. However, it may take a long time for all compilers to support this.

There are also two more troubling questions about inline functions. The first question is how to maintain it. A function may appear inline in the beginning, but as the system expands, the function body may require additional functionality, resulting in an inline function that becomes less likely, so it is necessary to remove the inline specifier and put the function body into a separate source file. Another problem arises when inline functions are applied to the code base. When the inline function changes, the user must recompile their code to reflect this change. However, for a non-inline function, the user simply needs to relink.

What you want to say here is that the inline function is not a panacea for performance enhancement. Only when the function is very short can it get the effect we want, but if the function is not very short and is called in many places, it will increase the volume of the executable body. The most annoying thing is when the compiler refuses to inline. In the old implementation, the results are very unsatisfactory, although in the new implementation of a great improvement, but still not so perfect. Some compilers are smart enough to point out which functions can be inline and which cannot, but most compilers are less intelligent, so this requires our experience to judge. If the inline function does not enhance the row energy, avoid using it!

C + + inline functions