(1) inline function (from the third edition of C ++ primer)
In the function declaration or definition, add the keyword inline before the function return type to specify 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 call point. Unlike non-inline functions, inline functions must be defined in each text file that calls the function. Of course, for different files of the same program, if the inline function appears, its definition must be the same. For compute. C and draw. for programs composed of C, programmers cannot define such a min () function. c Indicates one thing, but in draw. C refers to another thing. If the two definitions are different, the program will have undefined behavior:
To ensure that this will not happen, we recommend that you put the inline function definition in the header file. This header file is contained in each file that calls the inline function. This method ensures that there is only one definition for each inline function, and the programmer does not need to copy the code, and it is impossible to cause unintentional mismatch in the life of the program.
(2) programming style of inline functions (from the high quality c ++/C Programming Guide)
The keyword inline must be put together with the function definition body to make the function inline. Setting inline before the function declaration does not work..
The following function Foo cannot be an inline function:
Inline void Foo (int x, int y); // inline is only put together with the function declaration
Void Foo (int x, int y ){}
The following function Foo becomes an inline function:
Void Foo (int x, int y );
Inline void Foo (int x, int y) // put inline together with the function definition body {}
Therefore, inline is a "keyword used for implementation", rather than a "keyword used for Declaration ". Generally, you can read the declaration of a function, but cannot see the definition of a function. Although the inline keyword is added before the declaration and definition body of inline functions in most textbooks, I don't think inline should appear in the declaration of functions. Although this detail does not affect functions of functions, it reflects a basic principle of high quality c ++/C programming style: Declarations and definitions cannot be confused, the user does not need to know whether the function needs to be inline.
The member functions defined in the class declaration will automatically become inline functions.
For example
Class
{
Public: void Foo (int x, int y) {}// automatically becomes an inline function
}
Putting the definition body of the member function in the class declaration can bring convenience in writing, but it is not a good programming style. The above example should be changed:
// Header file
Class
{
Public:
Void Foo (int x, int y );
}
// Definition file
Inline void a: Foo (int x, int y ){}
Use inline with caution
Inner join can improve the execution efficiency of functions. Why not define all functions as inline functions? If all functions are inline functions, do you still need the keyword "inline? Inline is at the cost of code expansion (replication). It only saves the overhead of function calls and improves the function execution efficiency. If the execution time of code in the function body is higher than the overhead of function calling, the efficiency gains will be little. On the other hand, every call to an inline function must copy the code, which will increase the total amount of code in the program and consume more memory space.
Inline is not recommended in the following cases:
(1) If the code in the function body is long, using inline will cause high memory consumption.
(2) If there is a loop in the function body, the execution time of the Code in the function body is longer than the overhead of the function call. Class constructor and destructor are easy to misunderstand that using inline is more effective. Be careful that constructors and destructor may hide some behaviors, such as secretly executing constructors and destructor of base classes or member objects. Therefore, do not place the constructor and destructor definitions in the class declaration. A good compiler will automatically cancel the inline that is not worthwhile based on the definition body of the function (this further demonstrates that inline should not appear in the declaration of the function ).
Note:
Inline functions not only remove the efficiency burden caused by function calls, but also retain the advantages of general functions. However, inline functions are not a panacea, and in some cases, they can even reduce program performance. Therefore, you should be cautious when using it.
1. let's take a look at the benefits of inline functions: from a user's perspective, inline functions look like common functions. They can have parameters, return values, and scopes, however, it does not introduce the burden of General function calls. In addition, it is safer and easier to debug than macros.
Of course, we should be aware that inline specifier is only a suggestion for the compiler, And the compiler has the right to ignore this suggestion. How does the compiler determine whether the function is inline or not? Generally, key factors include the size of the function body, whether a local object is declared, and the complexity of the function.
2. What will happen if a function is declared as inline but not inline? Theoretically, when the compiler refuses to inline a function, the function will be treated like a common function, but there will be 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 common member function. However, the header file containing the class declaration will be separately # include into each independent compilation unit:
// 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 functions for this program:
Void F1 ();
Void F2 ();
Int main ()
{
F1 ();
F2 ();
Return 0;
}
When the program is linked, the linker will face two copies of the same time: Show (), so the function re-defines the connection error. However, some old c ++ implementations can deal with this situation by treating an un-inlined function as static. Therefore, each copy of the function is only visible in the compilation unit, so that the Link error is solved, but multiple copies of the function will be left in the program. In this case, the program performance is not improved, but the compilation and link time and the size of the final executable body are increased. Fortunately, the UN-inlined function in the new C ++ standard has changed. A c ++ implementation must generate only one copy of the function. However, it may take a long time for all compilers to support this.
There are two more headaches about inline functions. The first question is how to perform maintenance. A function may appear in an internal form at the beginning, but as the system expands, the function body may require additional functions, and the result inline function becomes unlikely, therefore, you need to remove the inline specifier and put the function body in a separate source file. Another problem is that inline functions are generated when they are applied to the code library. When the inline function changes, the user must recompile their code to reflect this change. However, for a non-inline function, you only need to relink it.
What I want to talk about here is that inline functions are not a panacea for improving performance. Only when a function is very short can it get the desired effect, but if the function is not very short and called in many places, it will increase the size of the executable body. The most annoying thing is when the compiler rejects inline. In the old implementation, the results were unsatisfactory. Although there were significant improvements in the new implementation, they were still not so perfect. Some compilers can be smart enough to point out which functions can be inline and which cannot, but most compilers are less intelligent. Therefore, we need our experience to judge. If the inline function cannot enhance the row performance, avoid using it!