When will you make a function inline and why?

Answer 1

Inline expansion relates to the way in which a function call is replaced with the function body in your compiled code. The idea is that by eliminating the function call, your code will be faster because you eliminate the overhead of the function call (which requires a lot of unnecessary pushing and popping from the call stack). However, if the function is large and is called many times throughout your code, the extra speed gained by eliminating the function calls might be outweighed by the performance lost due to the increased code size.

Thus you will make a function inline when you know that there will be an advantage in doing so. In reality, however, marking a function for inline expansion merely states to the compiler that inline expansion is desired but is not required. The compiler is free to ignore the request when it can find no advantage in doing so. Some compilers may provide alternative methods that allow the programmer to overrule the compiler, but these should generally be avoided unless you can be absolutely certain there is an advantage to be gained (which will require an intimate understanding of your compiler's optimisers). In most cases it is best to let the compiler decide when inline expansion should occur, because what may be suitable for one program may not be suitable for all programs.

Aside from implementation-specific methods, there are essentially two ways to mark a function as a candidate for inline expansion: implicitly and explicitly. Implicit inline expansion occurs automatically whenever you define a function within its own declaration. Explicit expansion occurs when the declaration and definition are separate, but the definition is explicitly marked inline and appears in the same translation unit as the declaration. Where there is only one .cpp file, the definition may appear in that .cpp file (the declaration should always be placed in a header), but in all other cases this would result in an "unresolved external symbol" error from the linker. Thus the definition must appear in a header.

Note that although a definition is also a declaration, for the purpose of this answer a definition provides implementation while a declaration does not (a declaration in this sense simply means a forward declaration that will be implemented elsewhere).

The problem with inline expansion (whether implicit or explicit) is that the implementation may be visible to the caller, because it must also be visible to the linker. Whether this is desirable or not depends upon the function's purpose. However, the recommended method is to use explicit inline expansion, particularly with class methods. Although you cannot hide implementations within headers, you can limit the exposure by keeping the implementation physically separate. Consumers are only interested in the interface, so there's little point in confusing them with non-essential information within the declaration, which includes the use of the inline keyword (only the definition should be explicitly marked for inline expansion).

In most cases, inline expansion should be limited to functions that contain very simple statements or expressions. These can often result in reducing code size as well as improving performance. However, the same can be said of more complex functions where the compiler's optimisers can eliminate redundant code through procedural integration (making large functions smaller). Increased code size is not necessarily a bad thing unless the application is CPU-bound and the increased code size would result in increased paging (commonly known as thrashing). For non-CPU-bound applications inline expansion is largely irrelevant because overall performance would ultimately be determined by the bottlenecks elsewhere, such as file systems, databases or networks.

Answer 2

The simple answer is we never make a function inline. That is, we should never force a compiler or linker to inline expand. The reason is simply that we do not have enough relevant information to determine whether a function should be inline expanded or not (and if you have to ask the question, you are simply not qualified to make that determination). Even if we could calculate the pros and cons of inline expansion, those calculations would rendered moot the next time we modified the program. We've got far better things to do with our time -- especially when the compiler and linker can make those calculations for us every time we compile our program. That's their job, not ours.

Of course, many inline expansions are patently obvious to us as programmers, however if they are obvious to us then they are obvious to the compiler and linker, so it's really not something we ever have to worry about, particularly when the compiler and linker can interweave code in far more intricate ways besides inline expansion. Indeed, enforcing an inline expansion can interfere with other optimisations, leading to sub-optimal code

Contrary to belief, the inline keyword does not actually enforce inline expansion. The inline keyword is really only required whenever we define a function in a header because headers do not normally contain definitions (only declarations). If we do not declare the definition inline, and that header is subsequently included in multiple source files (something that we can't always predict in advance), then that definition is going to be recompiled wherever the file is included, leading to slower compile times. By declaring the definition inline, the compiler can inform the linker that this is the one and only definition and let the linker decide whether inline expansion is appropriate. Indeed, the linker is primarily responsible for most inline expansions because, unlike the compiler, which can only see the current translation unit, the linker can see the whole program and interweave code in far more intricate ways.

Some compilers (most notably Microsoft compilers) include non-standard extensions to the C++ language, including the force_inline keyword. Unlike the standard inlinekeyword, this really does impose an inline expansion. But because it can undermine compiler optimisations in ways that are extremely difficult to predict without in-depth knowledge of the compiler and linker implementations, this keyword is best avoided. Trial and error will quickly tell you that there is very little to gained by enforcing your will upon the compiler; let it do the job it was specifically designed to do.