In the source code directory of the ACE, there is an active file .cpp, header file .h, we also found that there is a file with .i and .inl to extension. In fact, files for the extension of .i and .inl are the form of storage in the INLINE function in the ACE source code.
In this way, use this method in this way, we are conscious of the INLINE keyword before the Inline function is stored. We know that when a function is called, it involves some operations such as returning addresses and parameter stacks, which are the overhead of the function call itself. In the original C code, the macro definition method is usually used to eliminate the overhead of the function call, so we know that the macro is processed during the pre-transdermation. However, there are many flaws that macro definitions themselves, which is easy to use. This is the reason why the Inline keyword was born. Use the inline keyword definition, when compiled, do not generate a real function, but directly unfolding the code at the function call, so that the overhead of the function call is eliminated. Note that the inline keyword, just a hint to the compiler, is it true that INLINE is determined by the compiler.
What ACE will use such a special way to store the inline letter? We give an answer in conjunction with an example. Let's take a look at the end of the reactor.h file, there is the following processing: #if Defined (__Ace_inline __) # include "ace / Reactor.i" #ENDIF / * __ACE_INLINE__ * /
Looking at the macro of the reactor.cpp file: #IF! Defined (__Ace_inline __) # include "ace / reactor.i" #ENDIF / * __ACE_INLINE__ * /
The above Reactor.h, Reactor.cpp and Reactor.i files are related code for the Reactor framework of the ACE. The above macro definitions We are well understood, the processing in the header file is: Processing in the source file is: If there is no macro __Ace_inline__, then the Reactor.i file include in the source file. In fact, there is an introduction to the above inline mean, which is not difficult to understand why this approach is processed. Here we assume that the macro __ace_inline__, and the reactor.i file is in the include to the source file, not by the include header file, then what consequences? We know the inline function, after compiler, does not generate a real function, so if there are other source files, such as zhx.cpp, call the inline function in the reactor.i file, then when connected, Just throw the error that cannot be parsed, and if the reactor.i file is in the header file, and we have functions in the Reactor.i file in zhx.cpp, then in zhx.cpp, only need Contains the Reactor.h header file, then the related INLINE function of Reactor.i is also code unpacking processing in zhx.cpp. If there is no macro __Ace_inline__, Reactor.i is in the include to the source file, there is no problem, because the functions in Reactor.i are compiled, and the true function is generated instead of being processed by the inline. This is why the ACE is processed in such a way.
In the above introduction, we also discovered the shortcomings of Inline, which would cause the code to expand. Therefore, not what kind of function is suitable for use inline to define, only those short functions are suitable for use inline processing. Note: Why is the ACE uses two files in the form of two extensions. I am not very clear, but I feel that the file stored in .inl is the way in the early ACE code, the later ACE code Inline function is used in.
