I've just been researching the use and benefits/pitfalls of the C++ keyword inline on the Microsoft Website and I understand all of that.
My question is this: if the compiler evaluates functions to see if inlining them will result in the code being more efficient and the inline keyword is only a SUGGESTION to the compiler, why bother with the keyword at all?
EDIT: A lot of people are moaning about my use of __inline instead of inline. I'd like to point out that __inline is the Microsoft specific one: so it's not wrong, it's just not necessarily what you're used to. (Also fixed the website link)
EDIT2: Re-formatted the question to indicate the inline keyword (used across all of C++) instead of the Microsoft-specific __inline keyword.
Firstly, it is not __inline, but inline.
Secondly, the effect inline has within the One Definition Rule is undeniably significant. It allows you to define the functions multiple times and have the compiler to handle it.
Thirdly, with regard to the actual inilining this is your way to express your opinion about that function not only to the compiler but also to those who might read your code later. In many cases it is a way to let off the steam, so to say. Basically, it is a way for you to tell the others and yourself: "I feel that this function is too small (or too specialized) to justify the calling overhead, so don't hold me responsible for this travesty. I did all I could. If not for your stupid company-wide coding standard, I would've made it a macro". In that regard it is a sort of formalized comment.
Fourthly, seeing that you used an implementation-specific spelling of the keyword, I'd note that some implementations offer you alternative keywords that give you the opportunity to be more... er... persuasive in your desire to have that function inlined. In MS compiler that would be __forceinline.
The keyword is inline and not __inline.
inline is not a mere suggestion it is the best standard compliant way to include a function definition in a header file without breaking the one definition rule.
Judging from the documentation in MSDN, I think it's a purely pragmatic thing, mostly for the benefit of C programs.
Since inline is a valid identifier name in C, another keyword is needed in C.
Personally, I would only consider using it if my source code could end up being shared between C and C++ programs (in Visual Studio, obviously).
Related
On the cppreference page for the inline specifier, it says,
The inline specifier, when used in a function's decl-specifier-seq, declares the function to be an inline function.
An inline function has the following properties:
There may be more than one definition of an inline function in the program as long as each definition appears in a different translation unit and all definitions are identical.
...
Then, a bit down, it says,
The original intent of the inline keyword was to serve as an indicator to the optimizer that inline substitution of a function is preferred over function call. ...
Apart from this line, there is no reference to this use of inline. Is the latter meaning of inline still valid in the C++ standards? Or is the latter form deprecated over the former?
If the latter form is still valid, is it worth using it in modern compilers? I have heard that, even though it is the compiler that makes the decision about inlining, using the inline keyword pushes it a bit. Is this true? Should I use the inline keyword in my program for this case?
The standard doesn't concern itself with how the assembly is generated, so "inlining" a function can't be mandated in it.
[dcl.inline]/2 words this as a recommendation:
... indicates to the implementation that inline substitution of the function body at the point of call is to be preferred ...
An implementation is not required to perform this inline substitution ...
This blog post suggests that GCC and Clang do respect the inline hint to a certain degree.
Or the latter form is deprecated over the former?
As can be seen in [dcl.inline]/2, it's not.
I originally wanted to say that they can't deprecate it because they can't mandate it, but they failed to mark their recommendation as "note" (which would mean that it lacks the "standardizing power"), which looks like an editoral error to me.
The inline keyword makes it possible that all translation units will have access to the definition of a function, which will make it much easier for the compiler to inline the function instead of calling it. So, yes, it does facilitate inlining, though it doesn't (and has never) mandated it.
Should you use the inline keyword when you want the function to be inlined? Probably not, because you're probably wrong about how that will affect the performance. Note that inlining is still possible across translation units on major compilers if you turn on link time optimizations. So I recommend you do that and leave the rest to the compiler.
Also note that many compilers have extensions to more strongly recommend the compiler to inline a function, like always_inline in GCC. If you're going to use those, I recommend you profile your code before and after to see if you're helping or hurting the performance of your code.
!! Specific on frequently used methods like getter & setter. !!
I have no idea when the keyword inline should be used. Ofc I know what it does, but I still have no idea.
According to an interview with Bjarne Stroustrup he said:
My own rule of thumb is to use inlining (explicitly or implicitly) only for simple one- or two-line functions that I know to be frequently used and unlikely to change much over the years. Things like the size() function for a vector. The best uses of inlining is for function where the body is less code than the function call and return mechanism, so that the inlined function is not only faster than a non-inlined version, but also more compact in the object core: smaller and faster.
But I often read that the compiler automatically inline short functions like getter, setter methods (in this case getting the size() of a vector).
Can anyone help?
Edit:
Coming back to this after years and more experience the high performance C+++ programming, inline can indeed help. Working in the games industry even forceinline sometimes makes a difference, since not all compilers work the same. Some might inline automatically some don't.
My advice is if you work on frameworks, libraries or any heavily used code consider the use of inline, but this is just general advice anyway since you want such code to be fully optimized for any compiler. Always using inline might not be the best, because you'll also need the class definition for this part of the code. Sometimes this can increase compilation times if you can't use forward declarations anymore.
another hint: you can use C++14 auto return type deduction even with seperating the function definition:
MyClass.h
class MyClass
{
int myint;
public:
auto GetInt() const;
}
inline auto MyClass::GetInt() const { return myint; }
all in one .h file.
Actually, inline keyword is not for the compiler anymore, but for the linker.
That is, while inline in function declaration still serves for most compilers as a hint, on high optimization setting they will inline things without inline and won't inline things with inline, if they deem it better for the resulting code.
Where it is still necessary is to mark function symbols as weak and thus circumvent One Definition Rule, which says that in given set of object files you want to make into a binary, each symbol (such as function) shall be present only once.
Bjarne's quote is old. Modern compilers are pretty smart at it.
That said, if you don't use Link Time Code Generation, the compiler must see the code to inline it. For functions used in multiple .cpp files, that means you need to define them in a header. And to circumvent the One Definition Rule in that case, you must define those functions as inline.
Class members defined inside the class are inline by default, though.
The below speaks specifically to C++:
The inline keyword has nothing to do with inlining.
The inline keyword allows the same function to be defined multiple times in the same program:
Every program shall contain exactly one definition of every non-inline function or variable that is odr-used in that program; no diagnostic required.
§3.2 [basic.def.odr]
Attaching meaning beyond this to the inline keyword is erroneous. The compiler is free to inline (or not) anything according to the "as-if rule":
A conforming implementation executing a well-formed program shall produce the same observable behavior as one of the possible executions of the corresponding instance of the abstract machine with the same program and the same input.
§1.9 [intro.execution]
Considering what compiler optimizations can do, the only use of inline I have today is for non-template function whose body is defined inside headers files outside class bodies.
Everything is defined (note: defined != declared) inside class bodies is inline by default, just as templates are.
The meaning of inline in fact is: "Defined in header, potentially imported in multiple sources, just keep just one copy of it" told to the linker.
May be in c++35 someone will finally decide to replace that keyword with another one more meaningful.
C++ standard Section 7.1.2 Point 2:
(...) The inline specifier indicates to the implementation that
inline substitution of the function body at the point of call is to be
preferred to the usual function call mechanism. An implementation
is not required to perform this inline substitution at the point of
call (...)
In other words instead of havin a single code for your function, that is called several times, the compiler may just duplicate your code in the various places the function is called. This avoids the little overhead related to the function call, at the cost of bigger executables.
Be aware that inline keyword may be used also with namespaces, but with a very different meaning. Members of an inline namespace can be used in most respects as though they were members of the enclosing namespace. (see Standard, section 7.3.1 point 8).
Edit:
The google style guide recommends to inline only when a function is ten lines or less.
I'm answering the question my self!: Solution: After a few performance tests, the rule of thumb from Stroustrup is right! inlining Short functions like the .size() from vector can improve the performance (.size() calls are used frequently). But the impact is only noticeable for FREQUENTLY used functions. If a getter/setter method is used a lot, inlining it might increase the performance.
Stroustrup:
Don’t make statements about “efficiency” of code without first doing
time measurements. Guesses about performance are most unreliable.
With one being the 'optimization' effect, and the other being the effect related the the ODR.
To me those two seem like completely unrelated things, so I'm having a hard time understanding why the same keyword is used for both.
compare with the many uses of const, static and auto (et al)
the C++ Committee is positively allergic to reserving new keywords.
Techinically, I don't think it actually changes the ODR - you are only supposed to provide one definition (this definition can occur multiple times, but it should be the same). I'm a bit too lazy to look up the exact words of the specification, but I remember from a previous discussion on this subject that "you must not have a different declaration elsewhere" (in other words, the actual code itself should be the same every time).
As to why: Because the original usage is still what inline intends - it's just that compilers these days are smart enough to figure out when it's a good idea and when it isn't a good idea, to actually inline a function.
The key is that we need some way to tell the compiler and linker that "this function is the same function, even if you see it multiple times". One could invent a new keyword, but the more keywords that are used by the compiler, the fewer words we as programmers have available. And of course, ancient code would still be using the old keyword, so it still would need to be supported. I can't see much benefit in adding a new keyword that does the same as the existing one.
What is the relation between the two different effects of the inline keyword?
In a formal sense, when you inline a function there's no point of having external linkage for it and hence it also makes the function linkage interal (side effect).
why the same keyword is used for both
It is a typical case of where the side effect took over the mainline scenario i.e. today inline is just an opinion about the function by the programmer and the compiler has the final say on actually inlining the call; however the usage is more towards making a function have internal linkage when defining it in a header file.
See here and here.
There's two things about inlining:
The inline keyword will be ignored if the compiler determines that the function cannot be inlined.
There is a compiler optimization (on Visual Studio, I don't know about GCC) that tells the compiler to inline all functions where possible.
From this I conclude that I never need to bother about inlining. I just have to turn on the compiler optimization for the release build.
Or are there any situations where manually inlining would be preferred?
The inline keyword has two functions:
it serves as a hint to the compiler to perform the inlining optimization (this is basically useless on modern compilers, which inline aggressively with or without the keyword)
it tells the compiler/linker to ignore the One Definition Rule: that the inline'd symbol may be defined in multiple translation units (typically because it is defined in a header, that is included from multiple files). Normally, this would result in a linker error, but it is allowed when you use the inline keyword.
Yes, if you want to put a function in a header file, and include that file in several translation units. This is in fact the main purpose of inline in C++.
Manual use of inline might be useful on older compilers or less sophisticated compilers (such as compilers for embedded development). If you're using visual studio, I don't think you typically need to use the inline keyword at all.
Inline is also useful if you want the ability to inline functions from a library. Only by putting the code for the function in the header file (which requires inline), is the compiler able to inline the function. Of course it is still up the the compiler whether to inline the function or not.
There's a side effect of inline keyword when you are building shared library. Inlined functions are not exported into symbol table nor into library's binary. As a result inline keyword is crucial in aspect of shared libraries, since compiler won't be able to inline exported function. On the other hand library's inline function will be always inlined because it doesn't exist in the binary form of the library.
You may not want to inline everywhere it is possible. This could increase the size of your binaries too much. You may have a select few functions that aren't used very much that inlining would allow to run faster without increasing the size of your bits significantly
It depends on your environment and what you want to do, so it is really hard to say when inlining is preferrable.
This link has some interesting reading about inlining. And some sound advice (which pretty much boils down to: avoid doing it)
Read Herb Sutters comments on inline:
http://www.gotw.ca/gotw/033.htm
This question already has answers here:
Closed 13 years ago.
C++ ISO standard says: "A function defined within a class definition is an inline function." *
Do you know about any compilers that IGNORE this rule?
Do you know about any compilers that WILL NOT put that 'inline suggestion' there?
(please do not repeat the theory about inlines, I am aware of that - I need a practical answer)
All compilers are allowed to ignore any inline suggestions they decide to. If they decide the function is too complex, for example, it won't be inlined. If you ever take the address of the function, the function may be inlined in some places, but a full function generated somewhere else for the address to point to.
Think of inline and the implicit inline when you define a function in a class definition as suggestions to the compiler.
It is not a rule, it is simply a statement of fact. The spec is simply stating that the function is defined inline. That makes it easier for the compiler to actually inline the generated code as well, but nowhere does the standard require this.
They're different concepts. What the generated code looks like is up to the compiler alone, and the standard doesn't really impose any requirements (except of course that it should behave as specified).
In gcc you can use
-finline-limit=n
-fno-inline
See my answer to a very similar question: When is "inline" ineffective? (in C)
Summary: inline is only required to allow multiple definitions. Any function calling changes is purely optional.