Editing Inline function (section)

== Nonstandard extensions ==
[[GNU C]], as part of the dialect gnu89 that it offers, has support for <code>inline</code> as an extension to C89. However, the semantics differ from both those of C++ and C99. armcc in C90 mode also offers <code>inline</code> 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++: <code>__forceinline</code>
* gcc or clang: <code>__attribute__((always_inline))</code> or <code>__attribute__((__always_inline__))</code>, the latter of which is useful to avoid a conflict with a user-defined macro named <code>always_inline</code>.
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:
* <code>inline</code> 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:
<syntaxhighlight lang="cpp">
#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
</syntaxhighlight>