Inline function

An inline function can be written in C or C++ like this:

inline void swap(int *m, int *n)
{
    int tmp = *m;
    *m = *n;
    *n = tmp;
}

Then, a statement such as the following:

swap(&x, &y);

may be translated into (if the compiler decides to do the inlining, which typically requires optimization to be enabled):

int tmp = x;
x = y;
y = tmp;

When implementing a sorting algorithm doing lots of swaps, this can increase the execution speed.

C++ and C99, but not its predecessors K&R C and C89, have support for inline functions, though with different semantics. In both cases, inline does not force inlining; the compiler is free to choose not to inline the function at all, or only in some cases. Different compilers vary in how complex a function they can manage to inline. Mainstream C++ compilers like Microsoft Visual C++ and GCC support an option that lets the compilers automatically inline any suitable function, even those not marked as inline functions. However, simply omitting the inline keyword to let the compiler make all inlining decisions is not possible, since the linker will then complain about duplicate definitions in different translation units. This is because inline not only gives the compiler a hint that the function should be inlined, it also has an effect on whether the compiler will generate a callable out-of-line copy of the function (see storage classes of inline functions).

GNU C, as part of the dialect gnu89 that it offers, has support for inline as an extension to C89. However, the semantics differ from both those of C++ and C99. armcc in C90 mode also offers inline as a non-standard extension, with semantics different from gnu89 and C99.

Some implementations provide a means by which to force the compiler to inline a function, usually by means of implementation-specific declaration specifiers:

• Microsoft Visual C++: __forceinline
• gcc or clang: __attribute__((always_inline)) or __attribute__((__always_inline__)), the latter of which is useful to avoid a conflict with a user-defined macro named always_inline.

Indiscriminate uses of that can result in larger code (bloated executable file), minimal or no performance gain, and in some cases even a loss in performance. Moreover, the compiler cannot inline the function in all circumstances, even when inlining is forced; in this case both gcc and Visual C++ generate warnings.

Forcing inlining is useful if:

• inline is not respected by the compiler (ignored by compiler cost/benefit analyzer)
• inlining results is necessary for boosting performance

For code portability, the following preprocessor directives may be used:

#ifdef _MSC_VER
    #define forceinline __forceinline
#elif defined(__GNUC__)
    #define forceinline inline __attribute__((__always_inline__))
#elif defined(__CLANG__)
    #if __has_attribute(__always_inline__)
        #define forceinline inline __attribute__((__always_inline__))
    #else
        #define forceinline inline
    #endif
#else
    #define forceinline inline
#endif

static inline has the same effects in all C dialects and C++. It will emit a locally visible (out-of-line copy of the) function if required.

Regardless of the storage class, the compiler can ignore the inline qualifier and generate a function call in all C dialects and C++.

The effect of the storage class extern when applied or not applied to inline functions differs between the C dialects[2] and C++.[3]

Taking the address of an inline function requires code for a non-inlined copy of that function to be emitted in any case.

In C99, an inline or extern inline function must not access static global variables or define non-const static local variables. const static local variables may or may not be different objects in different translation units, depending on whether the function was inlined or whether a call was made. Only static inline definitions can reference identifiers with internal linkage without restrictions; those will be different objects in each translation unit. In C++, both const and non-const static locals are allowed and they refer to the same object in all translation units.

gcc cannot inline functions if[3]

1. they are variadic,
2. use alloca
3. use computed goto
4. use nonlocal goto
5. use nested functions
6. use setjmp
7. use __builtin_longjmp
8. use __builtin_return, or
9. use __builtin_apply_args

Based on Microsoft Specifications at MSDN, MS Visual C++ cannot inline (not even with __forceinline), if

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.

Besides the problems with inline expansion in general (see Inline expansion § Effect on performance), 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.
• The specification of inline in C99 requires exactly one external definition of the function, if it is used somewhere. If such a definition wasn't provided by the programmer, that can easily lead to linker errors. This can happen with optimization turned off, which typically prevents inlining. Adding the definitions, on the other hand, can cause unreachable code if the programmer does not carefully avoid it, by putting them in a library for linking, using link time optimization, or static inline.
• In C++, it is necessary to define an inline function in every module (translation 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. Depending on the compiler, this may cause each respective object file to contain a copy of the function's code, for each module with some use that could not be inlined.
• In embedded software, oftentimes certain functions need to be placed in certain code sections by use of special compiler instructions such as "pragma" statements. Sometimes, a function in one memory segment might need to call a function in another memory segment, and if inlining of the called function occurs, then the code of the called function might end up in a segment where it shouldn't be. For example, high-performance memory segments may be very limited in code space, and if a function belonging in such a space calls another large function that is not meant to be in the high-performance section and the called function gets inappropriately inlined, then this might cause the high-performance memory segment to run out of code space. For this reason, sometimes it is necessary to ensure that functions do not become inlined.

"A function declaration [ . . . ] with an inline specifier declares an inline function. The inline specifier indicates to the implementation that inline substitution of the function body at the point of call is to be preferred to the usual function call mechanism. An implementation is not required to perform this inline substitution at the point of call; however, even if this inline substitution is omitted, the other rules for inline functions defined by 7.1.2 shall still be respected."

— ISO/IEC 14882:2011, the current C++ standard, section 7.1.2

"A function declared with an inline function specifier is an inline function. [ . . . ] Making a function an inline function suggests that calls to the function be as fast as possible. The extent to which such suggestions are effective is implementation-defined (footnote: For example, an implementation might never perform inline substitution, or might only perform inline substitutions to calls in the scope of an inline declaration.)

"[ . . . ] An inline definition does not provide an external definition for the function, and does not forbid an external definition in another translation unit. An inline definition provides an alternative to an external definition, which a translator may use to implement any call to the function in the same translation unit. It is unspecified whether a call to the function uses the inline definition or the external definition."

— ISO 9899:1999(E), the C99 standard, section 6.7.4

• Macro (computer science)

• Inline functions with the GNU Compiler Collection (GCC)
• Summary of "inline" semantics in C and C++, by LLVM contributor David Chisnall