Thanks to inline, the compiler can replace the function call with the function body. There are two reasons to use inline functions: performance and safety.
My primary goal was to write this post about performance. Fortunately, a further significant benefit of inline came to my mind. inline makes macros a function replacement superfluous.
Macro must go
Macros are only the poor man’s means to replace text. Macros have no understanding of the C++ syntax. Therefore, a lot can go wrong.
The macro in line 5, as the inline function in lines 7 – 9, returns the absolute value of its arguments. I invoke the function with the argument ++i. i is 0. The result should be 1. It should be because the macro increments the expression i two times. Consequently, the result is 2 instead of 1. The function func shows it explicitly. When I use the function func as an argument, the function will be invoked two times in the case of the macro but only once in the case of the inline function.
What’s happening if I use an inline function?
At first, all behave not as it seems. The compiler will interpret it only as a recommendation if I declare a function as inline. The compiler is free to ignore my recommendation. But it will also work the other way around. Modern compilers like Microsoft Visual C++, gcc, or clang can inline a function if it makes sense from a performance perspective.
Now I have to write in the conjunctive. We must assume the compiler will accept my recommendation and apply the inline keyword in the exchange function.
What’s happening at the function invocation?
The compiler substitutes the function call by the function body.
The small example shows the advantages and disadvantages of inline a function.
- No function call is necessary.
- Variables have not to be pushed onto or removed from the function stack.
- The function needs no return value.
- The instruction cache can be used optimally. New instructions don’t have to be loaded but can be immediately performed.
- The size of the executable grows.
Although I only mentioned one disadvantage that should not be judged. The usage of the keyword inline is a balance between performance versus the size of the executable. That was the simple rule. The details are a lot more complicated. Using inline, the executable may become faster or slower, bigger or smaller. inline can cause or prevent the crash of your program. inline case increases or decreases the number of cache misses of your program. Those who want to be confused should read the FAQ about inline functions at isocpp.org.
Until this point, I only wrote about functions. Of course, you can also declare methods as inline.
A method can become implicitly and explicitly inline implicitly if you define the method in the class body explicitly if you define the methods outside the class body and use the keyword inline.
Therefore, the method implicitInline (line 5) is inline because I defined it in the class boy. Therefore, the method explicitInline (line 6) is inline because I used the keyword inline at the point of the method definition. I want to stress one point. If I use only the keyword inline at the point of the method declaration, I will not get an inline function. This error happened to me with the method notInline (line 7).
Good advice is expensive. Should you use the keyword inline ever or never? Of course, the answer is not so simple. You should use inline if you have a function that is time critical and you invoke this function not too often. In this case, the performance advantages will dominate the size disadvantages.
But we have to keep the big picture in our mind. The Working Group WG 21 wrote the paper ISO/IEC TR 18015 about C++ performance in 2006. Chapter 5.3.4 of the paper explicitly discusses the keyword inline on five popular C++ compilers. They compare in this chapter functions, inline functions, and macros. The conclusion in the paper is that inline function calls are about 2-17 times faster than function calls and that inline function calls and macros are in the same performance range.
If this rule of thumb is too simple for you, you should measure the performance of your program. This is, in particular, true for embedded systems that have more substantial resource concerns.
After getting much attention at Reddit for missing the main point about inline functions I will add a few words about ODR.
ODR stands for the One Definition Rule and says in the case of a function.
- A function can have not more than one definition in any translation unit.
- A function can have not more than one definition in the program.
- Inline functions with external linkage can be defined in more than one translation. The definitions must satisfy the requirement that each must be the same.
In modern compilers, the keyword inline is not about inlining functions anymore. Modern compilers almost completely ignore it. The more or less use-case for inline is to mark functions for ODR correctness. In my opinion, the name inline is nowadays quite misleading.
C versus C++
Sorry, the confusion will not end here. I want to stress that point explicitly.inline function by default has external linkage in C++. This is different from C. In C, inline functions, by default, have internal linkage. You can read the details in the article Linkage of inline functions.
This was a post about classical C++. In the next post, I will write about C++11. C++11 has the keyword constexpr. You can use constexpr for values, functions, and user-defined data types. By constexpr declared constant expression can be evaluated at compile time. They offer a lot of benefits. Which? You will see it in the next post.
Thanks a lot to my Patreon Supporters: Matt Braun, Roman Postanciuc, Tobias Zindl, G Prvulovic, Reinhold Dröge, Abernitzke, Frank Grimm, Sakib, Broeserl, António Pina, Sergey Agafyin, Андрей Бурмистров, Jake, GS, Lawton Shoemake, Jozo Leko, John Breland, Venkat Nandam, Jose Francisco, Douglas Tinkham, Kuchlong Kuchlong, Robert Blanch, Truels Wissneth, Kris Kafka, Mario Luoni, Friedrich Huber, lennonli, Pramod Tikare Muralidhara, Peter Ware, Daniel Hufschläger, Alessandro Pezzato, Bob Perry, Satish Vangipuram, Andi Ireland, Richard Ohnemus, Michael Dunsky, Leo Goodstadt, John Wiederhirn, Yacob Cohen-Arazi, Florian Tischler, Robin Furness, Michael Young, Holger Detering, Bernd Mühlhaus, Matthieu Bolt, Stephen Kelley, Kyle Dean, Tusar Palauri, Dmitry Farberov, Juan Dent, George Liao, Daniel Ceperley, Jon T Hess, Stephen Totten, Wolfgang Fütterer, Matthias Grün, Phillip Diekmann, Ben Atakora, Ann Shatoff, Rob North, Bhavith C Achar, and Marco Parri Empoli.
Thanks, in particular, to Jon Hess, Lakshman, Christian Wittenhorst, Sherhy Pyton, Dendi Suhubdy, Sudhakar Belagurusamy, Richard Sargeant, Rusty Fleming, John Nebel, Mipko, Alicja Kaminska, Slavko Radman, and David Poole.
|My special thanks to Embarcadero|
|My special thanks to PVS-Studio|
|My special thanks to Tipi.build|
|My special thanks to Take Up Code|
I’m happy to give online seminars or face-to-face seminars worldwide. Please call me if you have any questions.
- Embedded Programmierung mit modernem C++ 12.12.2023 – 14.12.2023 (Präsenzschulung, Termingarantie)
Standard Seminars (English/German)
Here is a compilation of my standard seminars. These seminars are only meant to give you a first orientation.
- C++ – The Core Language
- C++ – The Standard Library
- C++ – Compact
- C++11 and C++14
- Concurrency with Modern C++
- Design Pattern and Architectural Pattern with C++
- Embedded Programming with Modern C++
- Generic Programming (Templates) with C++
- Clean Code with Modern C++
- Phone: +49 7472 917441
- Mobil:: +49 176 5506 5086
- Mail: schulung@ModernesCpp.de
- German Seminar Page: www.ModernesCpp.de
- Mentoring Page: www.ModernesCpp.org
Modernes C++ Mentoring,