Inline Function - Microsoft Visual C++ Specific

Microsoft Visual C++ Specific

Microsoft Visual C++ and few other compilers support non-standard constructs for defining inline functions, such as __inline and __forceinline specifiers.

• The __inline keyword is equivalent to inline.
• The __forceinline keyword allow the programmer to force the compiler to inline the function, but indiscriminate use of __forceinline can result in larger code (bloated executable file), minimal or no performance gain, and in some cases even a loss in performance. The compiler cannot inline the function in all circumstances, even with the __forceinline keyword applied. If the compiler cannot inline a function declared with __forceinline, a warning of level 1 is generated. A list of cases when __forceinline will not take effect is listed below (based on Microsoft Specifications at MSDN):

1. The function or its caller is compiled with /Ob0 (the default option for debug builds).
2. The function and the caller use different types of exception handling (C++ exception handling in one, structured exception handling in the other).
3. The function has a variable argument list.
4. The function uses inline assembly, unless compiled with /Og, /Ox, /O1, or /O2.
5. The function is recursive and not accompanied by #pragma inline_recursion(on). With the pragma, recursive functions are inlined to a default depth of 16 calls. To reduce the inlining depth, use inline_depth pragma.
6. The function is virtual and is called virtually. Direct calls to virtual functions can be inlined.
7. The program takes the address of the function and the call is made via the pointer to the function. Direct calls to functions that have had their address taken can be inlined.
8. The function is also marked with the naked __declspec modifier.

__forceinline is useful if:

• inline or __inline is not respected by the compiler (ignored by compiler cost/benefit analyzer)
• code portability is not required
• inlining results in a necessary performance boost

Example of portable code:

Besides the problems associated with inline expansion in general, inline functions as a language feature may not be as valuable as they appear, for a number of reasons:

• Often, a compiler is in a better position than a human to decide whether a particular function should be inlined. Sometimes the compiler may not be able to inline as many functions as the programmer indicates.
• An important point to note is that the code (of the inline function) gets exposed to its client(the calling function).
• As functions evolve, they may become suitable for inlining where they were not before, or no longer suitable for inlining where they were before. While inlining or un-inlining a function is easier than converting to and from macros, it still requires extra maintenance which typically yields relatively little benefit.
• Inline functions used in proliferation in native C-based compilation systems can increase compilation time, since the intermediate representation of their bodies is copied into each call site where they are
• The specification of inline in C99 requires exactly one additional external definition of a function in another compilation unit, when the corresponding inline definition, that can occur multiple times in different compilation units, if that function is used somewhere. That can easily lead to linker errors because such a definition wasn't provided by the programmer. For this reason, inline in C99 often is used together with static, which gives the function internal linkage.
• In C++, it is necessary to define an inline function in every module (compilation unit) that uses it, whereas an ordinary function must be defined in only a single module. Otherwise it would not be possible to compile a single module independently of all other modules.

For problems with the optimization itself, rather than the language feature, see problems with inline expansion.