Valid tive C ++: Clause 30: A thorough understanding of inlining's internal and external

(1)

Inline functions can call them without the additional overhead incurred by function calls.

The overall idea behind the inline function is to replace "every call to this function" with the function ontology, which may increase the size of your object code. On machines with limited memory, excessive inline will cause too many programs, leading to page feed, lowering the cache hit rate, and other behaviors that will cause efficiency loss. If the inline function ontology is small, the code generated by the compiler for the "function ontology" may be smaller than the code generated for the "function call. Using the inline function can lead to a smaller target code, thus improving the efficiency.

(2)

Inline is only an application for the compiler, not a mandatory command. This kind of application can be either proposed by metaphor or explicitly.

(1) Proposal of metaphor (the metaphor is to define the function within the class definition ):

Class Person {public:... int age () const {return theAge;} // a metaphor for inline application... private: int theAge ;};

(2) explicitly put forward (by explicitly applying for an inline function, add the keyword "inline" before its definition ):

template
 
   inline const T& std::max(const T& a, const T& b) {     return a < b? b: a; }
 

(3)

(1) If we are writing a template and we think that all functions available based on this template should be inlined, declare this template as inline;

If the template has no reason to require that every function it has is inlined, avoid declaring this template as inline (whether explicit or implicit ). Inline requires cost.

(2) Most compilers reject inlining functions that are too complex (such as loops or recursion), and all calls to virtual functions will also result in inlining failure. Because virtual means "waiting until the runtime determines which function to call", and inline means "before execution, replace the called action with the called function ontology ". If the compiler does not know which function to call, it will certainly not be able to be inlining!

(3) Sometimes, although the compiler is willing to inlining a function, it is possible to generate a function Ontology for the function. For example, if the program needs to obtain the address of an inline function, because the compiler usually needs to generate an outlined function Ontology for this function (after all, the compiler cannot propose a pointer to a function that does not exist ), therefore, the compiler usually does not implement inlining for "calling through function pointers.

Inline void f (){...} // Assume that the compiler is willing to inline "Call to f" void (* pf) () = f; f (); // this call will be inlined, because it is a normal call pf (); // This call may not be inlined, because it is achieved through the pointer

(4)

Class base {public :... private: std: string bm1, bm2;}; class Derived: public Base {public: Derived () {}// is the Derived constructor empty? ... Private: std: string dm1, dm2, dm3 ;};

This constructor looks like a perfect candidate for inlining because it does not contain any code,:

C ++ provides various guarantees for "what happens when an object is created and destroyed. The compiler generates code for the seemingly empty Derived constructor, which is equivalent to the following:

Derived::Derived() {    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 piece of code does not represent the Code actually manufactured by the compiler, because the real compiler will handle exceptions in a more sophisticated and complex way. however, this accurately reflects the actions that the Derived blank constructor must provide. The Derived constructor will at least call the constructor of its member variables and baseclass one after another. Those calls (which may also be inlined) will affect the compiler's inlining function.

(5)

The library designer must evaluate the impact of "declaring a function as inline": the inline function cannot be upgraded as the library is upgraded.

The customer compiled the "f function ontology" into the program. Once the library designer decides to change f, all client programs that use f must be re-compiled. However, if f is a non-inline function, the client only needs to reconnect. If the library uses a dynamic link, the upgraded function can even be absorbed by the application without knowing it.

Remember:

(1) limit most inlining to small and frequently called functions, which makes debugging and binary upgrade easier in the future. It can also minimize potential code expansion problems and maximize the program's speed.

(2) do not declare function templates as inline because they appear in the header file.