Article 30: A thorough understanding of inline's internal and external

Why use the inline function?
It looks like a function, but there is no overhead for pushing the stack out of the stack when the function is called. In addition, we know that the optimal compiler mechanism is usually designed to concentrate those "without function calls ".Code. So when you inline a function, the compiler has the ability to perform contextual Optimization on it.

But not all functions become inline. We know that after inline,ProgramThe target code will become larger. If you run on a machine with a small memory, it will lead to too many page changes, reduce the hit rate of high-speed cache ink, and the resulting inefficiency.
From another perspective, if the inline ontology is small, the Code produced by the compiler for the "function ontology" may be smaller than the code produced by the call, which is indeed good and will reduce the amount of the target code, increase the hit rate of the cache device.

Inline functions are usually placed in the header file, because most build environments perform inline during compilation, to replace a "function call" with "called function ontology ", the compiler must know what the function looks like.
Now we need to understand that "inline is an application and the compiler can ignore it ".
Most compilers ignore too complex functions, and calls to all virtual functions will also result in inline failure. Think about why? Because Virtual means "waiting until RunTime", and inline means to replace the call action with the called function ontology before execution. If the compiler does not know which function to call, it is hard to blame them for rejecting the function ontology inline.

Sometimes, although we are willing to call a function inline, it is not necessarily successful. It depends on your call method: for example, you want to call the function through the function pointer.

Inline void F () {...} // Inline Function
Void (* PF) () = F; // defines a pointer pointing to function f
...
F (); // inline will be executed
PF (); // it will not be called by inline because it is called through the function pointer.

Why can't I use function pointers? We know that during compilation, we only know that PF is a function pointer, but we do not know the value in it. We do not know it until it is running. No. So it cannot pass the function pointer inline.
In fact, constructor and destructor are often bad candidates for inline.

Class base {
Public:
...
PRIVATE:
STD: String bm1, bm2;
};

Class derived: public base {
Public:
Derirved () {}// is it really null?
...
PRIVATE:
STD: String DM1, dm2, dm3;
};

We know that there are many things to do when an object is created and destroyed. For example, calling a base class constructor ..., Therefore, the derived () function in the derived class is not empty. The compiler will add a lot of things. For example:

Derirved (){
Base: Base ();
Try
{
Dm1.std: String: string ();
}
Catch (...)
{
Base ::~ Base (); throw;
}
Try
{
Dm2.std: String: string ();
}
Catch (...)
{
Dm1.std: String ::~ String ();
Base ::~ Base (); throw;
}
Try
{
Dm3.std: String: string ();
}
Catch (...)
{
Dm2.std: String ::~ String ();
Dm1.std: String ::~ String ();
Base ::~ Base (); throw;
}
}

This indicates that the constructor is not empty. This means that the constructor should not all be defined in the class definition body (because it is an implicit inline ). The same principle applies to destructor.
Therefore, you will understand that setting a function as inline is very knowledgeable.

There is another problem here: if the inline function is modified internally, all the code that calls this inline function will be re-compiled. If a non-inline function is modified internally, you only need to re-link the function.

Remember:

• Limit most inlines to small and frequently called functions. This makes the debugging process and binary upgrade easier in the future, and minimizes potential code expansion problems, maximizing the program's speed increase.