0

I saw a piece of information about behavior of C++ compilers with inline function as below, which says:

https://cplusplus.com/doc/tutorial/functions/

When function is declared with inline, most compilers already optimize code to generate inline functions when they see an opportunity to improve efficiency; Even if not explicitly marked with the inline specifier. Therefore, this specifier merely indicates the compiler that inline is preferred for this function, although the compiler is free to not inline it, and optimize otherwise. In C++, optimization is a task delegated to the compiler, which is free to generate any code for as long as the resulting behavior is the one specified by the code.

If its delegated to compiler, which functions has to inline and which not, as per optimization, can we always declare a function as inline ? After all, it would be done by compiler if its optimum.

Remy Lebeau
  • 555,201
  • 31
  • 458
  • 770
Rishi
  • 75
  • 7
  • 3
    "This specifier merely indicates the compiler that inline is preferred for this function" not really, anymore. At this point the [inline specifier](https://en.cppreference.com/w/cpp/language/inline) is used to tell the linker that multiple identical definitions of the function can be expected to be found in multiple translation units and that this is fine. [This answer](https://stackoverflow.com/a/1759575/12334309) has more. – Nathan Pierson Oct 19 '22 at 03:29
  • 1
    The premise that a function is always optimal inline is not necessarily true. Overly aggressive inlining can cause the code to become unnecessarily large, which causes excess evictions of the instruction cache and other caches in the processor, more page faults, etc. – nanofarad Oct 19 '22 at 03:30
  • 4
    inline says to the compiler/linker : if you find more then one implementation of this function you can safely assume that the implementation will be the same for all of them. During linking the linker thus is free to pick any of the implementations. For example this allows you to put function definitions (implementation) in header files. Whether or not to remove a function call and "inline" the function is a choice usually left to the compiler. – Pepijn Kramer Oct 19 '22 at 03:35

1 Answers1

3

As general rules:

You should mark a function inline if you intent to define it in a header file (included by multiple translation units, aka .cpp files). It is not allowed to define a function which is not inline in multiple translation units. So this is necessary.

If the function is also static (at namespace scope), constexpr, is a function template or is defined inside a class definition, then inline is redundant and can/should be left out.

If the function is defined in a .cpp file and only used in this one translation unit it may be declared inline, but any performance implications of that are at best going to be minimal. A compiler will make its own decision on inlining anyway. inline is either completely ignored or a minor hint in the decision making process at best.

If the function is defined in a .cpp file and a declaration of it is included in multiple translation units via a header file, then it must not be declared inline. The inline specifier implies that you guarantee that a definition of the function will be available in any translation unit using it (and that all definitions will be identical).

The thing that is really performance-relevant here is not the inline specifier as such, but making the decision of whether you want to include the function definition in all translation units (meaning a header file) or only in one translation unit (meaning a .cpp file). Including in all translation units means that the compiler has it easier to perform inlining, not due to the inline keyword, but the fact that the definition is visible during the compilation process for the unit. However, nowadays we also have link time optimization which applies optimizations across all translation units when enabled and for which even that visibility of the definition doesn't really matter anymore.

user17732522
  • 53,019
  • 2
  • 56
  • 105