In the C and C++ programming languages, an inline function is one qualified with the keyword <code>inline</code>; this serves two purposes:
- It serves as a compiler directive that suggests (but does not require) that the compiler substitute the body of the function inline by performing inline expansion, i.e. by inserting the function code at the address of each function call, thereby saving the overhead of a function call. In this respect it is analogous to the <code>register</code> storage class specifier, which similarly provides an optimization hint.
- The second purpose of <code>inline</code> is to change linkage behavior. This is necessary due to the C/C++ separate compilation + linkage model, specifically because the definition (body) of the function must be duplicated in all translation units where it is used, to allow inlining during compiling, which, if the function has external linkage, causes a collision during linking (it violates uniqueness of external symbols). C and C++ (and dialects such as GNU C and Visual C++) resolve this in different ways. and C++.
C99
In C99, a function defined <code>inline</code> will never, and a function defined <code>extern inline</code> will always, emit an externally visible function. Unlike in C++, there is no way to ask for an externally visible function shared among translation units to be emitted only if required.
If <code>inline</code> declarations are mixed with <code>extern inline</code> declarations or with unqualified declarations (ie., without <code>inline</code> qualifier or storage class), the translation unit must contain a definition (no matter whether unqualified, <code>inline</code>, or <code>extern inline</code>) and an externally visible function will be emitted for it.
A function defined <code>inline</code> requires exactly one function with that name somewhere else in the program which is either defined <code>extern inline</code> or without qualifier. If more than one such definition is provided in the whole program, the linker will complain about duplicate symbols. If, however, it is lacking, the linker does not necessarily complain, because, if all uses could be inlined, it is not needed. But it may complain, since the compiler can always ignore the <code>inline</code> qualifier and generate calls to the function instead, as typically happens if the code is compiled without optimization. (This may be the desired behavior, if the function is supposed to be inlined everywhere by all means, and an error should be generated if it is not.) A convenient way is to define the <code>inline</code> functions in header files and create one .c file per function, containing an <code>extern inline</code> declaration for it and including the respective header file with the definition. It does not matter whether the declaration is before or after the include.
To prevent unreachable code from being added to the final executable if all uses of a function were inlined, it is advised with the exception that gnu89 permits redefinition of an <code>extern inline</code> function as an unqualified function, while C99 <code>inline</code> does not. Thus, gnu89 <code>extern inline</code> without redefinition is like C99 <code>inline</code>, and gnu89 <code>inline</code> is like C99 <code>extern inline</code>; in other words, in gnu89, a function defined <code>inline</code> will always and a function defined <code>extern inline</code> will never emit an externally visible function. The rationale for this is that it matches variables, for which storage will never be reserved if defined as <code>extern</code> and always if defined without. The rationale for C99, in contrast, is that it would be astonishing if using <code>inline</code> would have a side-effect—to always emit a non-inlined version of the function—that is contrary to what its name suggests.
The remarks for C99 about the need to provide exactly one externally visible function instance for inlined functions and about the resulting problem with unreachable code apply mutatis mutandis to gnu89 as well.
gcc up to and including version 4.2 used gnu89 <code>inline</code> semantics even when <code>-std=c99</code> was explicitly specified. With version 5, This matches the traditional behavior of Unix C compilers for multiple non-<code>extern</code> definitions of uninitialized global variables.
Restrictions
Taking the address of an <code>inline</code> function requires code for a non-inlined copy of that function to be emitted in any case.
In C99, an <code>inline</code> or <code>extern inline</code> function must not access <code>static</code> global variables or define non-<code>const</code> <code>static</code> local variables. <code>const static</code> 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 <code>static inline</code> definitions can reference identifiers with internal linkage without restrictions; those will be different objects in each translation unit. In C++, both <code>const</code> and non-<code>const</code> <code>static</code> locals are allowed and they refer to the same object in all translation units.
GCC cannot inline functions if