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
Related
I think I fully understand the meaning of the inline keyword in C++. Specifically it means two only semi-related things:
The ODR rule is relaxed for the function declared inline. Thus you can have the same function symbol defined in multiple TUs without getting an error when linking them. This allows a function to be defined in a header.
It is a suggestion to the compiler that it should replace invocations of the functions with a copy of the function's compiled code, rather than a call instruction to the address of the function symbol.
I can understand that these two meanings are necessarily related in one direction: 2 must imply 1. #2 requires that the function definition be available to all TUs that invoke the function. Therefore the function definition must exist in multiple TUs. Therefore the ODR needs to be relaxed to avoid linker errors.
But my question is about the other direction - why is the language designed such that 1 must imply 2?
It seems reasonable, in some cases and for some design decisions, to want to be able to relax the ODR for a function, without suggesting to the compiler that it should actually inline the function code. If I have a function I want to distribute via a header file I must mark it as inline to relax the ODR (#1). But now I am forced into #2 even if I have specific knowledge that in terms of performance, the function is not a good candidate for inlining.
My understanding is that this unwanted implication does not exist for template functions. The ODR is automatically relaxed for template functions (as it must be). That allows me to use inline only as a performance suggestion.
I understand that distributing functions in header files, as opposed to e.g. a static library, can be a bad idea. But as a programmer, there is some possibility that I know what I am doing, and I would like that flexibility. I have that flexibility with template functions so why not non-template functions?
Or is there a portable way to relax the ODR without suggesting that the function be inlined? E.g. on MSVC you can do this:
__declspec(noinline) inline void Foo() {}
Here inline relaxes the ODR, but __declspec(noinline) requests that the compiler not actually inline the call. But __declspec(noinline) isn't portable.
Thanks!
But __declspec(noinline) isn't portable.
You can make it portable to all implementations that have an analogous attribute by using a platform detection macro. GCC and Clang have __attribute__((noinline)).
Another approach is to simply not care. The compiler still has the option to ignore the preference that it perceives to have been implied. If the inline expansion would be expensive (because the function is big), a smart compiler should refrain from expanding it.
The reason we have to define inline functions in the header is that each compilation unit where that function is called must have the entire definition in order to replace the call, or substitute it. My question is why are we forced to put a definition in a header file if the compiler can and does do its own optimisations of inlining, which would require it to dig into the cpp files where the functions are defined anyway.
In other words, the compiler seems to me to have the ability to see the function "declaration" in a header file, go to the corresponding cpp file and pull the definition from it and paste it in the appropriate spot in the other cpp. Given that this is the case, why the insistence of defining the function in the header, implying as if the compiler can't "see" into other cpp files.
The MSDN says about Ob2/ optimisation setting:
Ob2/ The default value. Allows expansion of functions marked as inline, __inline, or __forceinline, and any other function that the compiler chooses (My emphasis).
The reason we're forced to provide definitions of inline function in header files (or at least, in some form that is visible to the implementation when inlining a function in a given compilation unit) is requirements of the C++ standard.
However, the standard does not go out of its way to prevent implementations (e.g. the toolchain or parts of it, such as the preprocessor, compiler proper, linker, etc) from doing things a little smarter.
Some particular implementations do things a little smarter, so can actually inline functions even in circumstances where they are not visible to the compiler. For example, in a basic "compile all the source files then link" toolchain, a smart linker may realise that a function is small and only called a few times, and elect to (in effect) inline it, even if the points where inlining occurs were not visible to the compiler (e.g. because the statements that called the functions were in separate compilation units, the function itself is in another compilation unit) so the compiler would not do inlining.
The thing is, the standard does not prevent an implementation from doing that. It simply states the minimum set of requirements for behaviour of ALL implementations.
Essentially, the requirement that the compiler have visibility of a function to be inlined is the minimum requirement from the standard. If a program is written in that way (e.g. all functions to be inlined are defined in their header file) then the standard guarantees that it will work with every (standard compliant) implementation.
But what does this mean for our smarter tool-chain? The smarter tool-chain must produce correct results from a program that is well-formed - including one that defines inlined functions in every compilation unit which uses those functions. Our toolchain is permitted to do things smarter (e.g. peeking between compilation units) but, if code is written in a way that REQUIRES such smarter behaviour (e.g. that a compiler peek between compilation units) that code may be rejected by another toolchain.
In the end, every C++ implementation (the toolchain, standard library, etc) is required to comply with requirements of the C++ standard. The reverse is not true - one implementation may do things smarter than the standard requires, but that doesn't generate a requirement that some other implementation do things in a compatible way.
Technically, inlining is not limited to being a function of the compiler. It may happen in the compiler or the linker. It may also happen at run time - for example "Just In Time" technology can, in effect, restructure executable code after it has been run a few times in order to enhance subsequent performance [this typically occurs in a virtual machine environment, which permits the benefits of such techniques while avoiding problems associated with self-modifying executables].
The inline keyword isn't just about expanding the implementation at the point it was called, but in fact primarily about declaring that multiple definitions of a function may exist in a given translation unit.
This has been covered in other questions before, which can it explain much better than I :)
Why are class member functions inlined?
Is "inline" implicit in C++ member functions defined in class definition
No, compilers traditionally can't do this. In classic model, compiler 'sees' only one cpp file at a time, and can't go to any other cpp files. Out of this cpp file compiler so-called object file in platofirm native format, which is than linked using effectively linker from 1970s, which is as dumb as a hammer.
This model is slowly evolving. With more and more effective link-time optimizations (LTO) linkers become aware of what cpp code is, and can perform their own inlining. However, even with link-time optimization model compiler-done inlining and optimization are still way more efficient than link-time - a lot of important context is lost when cpp code is converted to intermediate format suitable for linking.
It's much easier for the compiler to expand a function inline if it has seen the definition of that function. The easiest way to let the compiler see the definition of a function in every translation unit that uses that function is to put the definition in a header and #include that header wherever the function will be used. When you do that you have to mark the definition as inline so that the compiler (actually the linker) won't complain about seeing the definition of that function in more than one translation unit.
C++ allows you to annotate functions with the inline keyword. From what I understand, this provides a hint (but no obligation) to the compiler to inline the function, thereby avoiding the small function calling overhead.
I have some methods which are called so often that they really should be inlined. But inline-annotated functions need to be implemented in the header, so this makes the code less well-arranged. Also, I think that inlining is a compiler optimization that should happen transparently to the programmer where it makes sense.
So, do I have to annotate my functions with inline for inlining to happen, or does GCC figure this out without the annotation when I compile with -O3 or other appropriate optimization flags?
inline being just a suggestion to compiler is not true & is misleading.There are two possible effects of marking a function inline:
Substitution of function definition inline to where the function call was made &
Certain relaxations w.r.t One definition rule, allowing you to define functions in header files.
An compiler may or may not perform #1 but it has to abide to #2. So inline is not just a suggestion.There are some rules which will be applied once function is marked inline.
As a general guideline, do not mark your functions inline just for sake of optimizations. Most modern compilers will perform these optimizations on their own without your help. Mark your functions inline if you wish to include them in header files because it is the only correct way to include a function definition in header file without breaking the ODR.
Common folklore is that gcc always decides on its own (based on some cost heuristics) whether to inline something or not (depending on the compiler/linker options, it can even do so at link time). You can observe this sometimes when using -Winline where gcc warns that an inline hint was ignored, it often even gives a reason.
If you want to know exactly what is going on, you probably have to read the source code of it, or take the word of someone who read it.
I was told long ago to make short functions/methods that are called often inline, by using the keyword inline and writing the body in the header file.
This was to optimize the code so there would be no overhead for the actual function call.
How does it look with that today? Does modern compilers (Visual Studio 2010's in this case) inline such short functions automatically or is it still "necessary" to do so yourself?
inline has always been a hint to the compiler, and these days compilers for the most part make their own decisions in this regard (see register).
In order to expand a function inline, the compiler has to have seen the definition of that function. For functions that are defined and used in only one translation unit, that's no problem: put the definition somewhere before it's used, and the compiler will decide whether to inline the function.
For functions that are used in more than one translation unit, in order for the compiler to see the definition of the function, the definition has to go in a header file. When you do that, you need to mark the function inline to tell the compiler and linker that it's okay that there's more than one definition of that function. (well, I suppose you could make the function static, but then you could end up wasting space with multiple copies)
Enable warning C4710, this will warn you if a function which you define as inline is not inlined by the compiler.
Enable warning C4711, this will warn you if the compiler inlines a function not designated for inlining.
The combination of these two warnings will give you a better understanding of what the compiler is actually doing with your code and possibly whether it is worth designating inline functions manually or not.
Generally speaking, the inline keyword is used more now to allow you to "violate" the one definition rule when you define a function in a header than to give the compiler a hint about inlining. Many compilers are getting really good at deciding when to inline functions or not, as long as the function body is visible at th4e point of call.
Of course if you define the function only in a source file non-inline, the compiler will be able to inline it in that one source file but not in any other translation unit.
Inlining may be done by a compiler in the following situations:
You marked the function as inline and
it's defined in a current translation unit or in file that it's included in it;
compiler decides that it's worth doing so. According to the MSDN
The inline keyword tells the compiler that inline expansion is preferred.
The compiler treats the inline expansion options and keywords as suggestions.
You used the __forceinline keyword (or __ attribute __((always_inline)) in gcc). This will make compiler to skip some checks and do the inlining for you.
The __forceinline keyword overrides the cost/benefit analysis and relies on the judgment of the programmer instead.
Microsoft compiler can also perform cross module inlining if you have turned on link time code generation by passing /GL flag to the compiler or /LTCG to the linker. It's quite clever in making such optimizations: try to examine the assembly code of modules compiled with /LTCG.
Please note, that inlining will never happen if your function is:
a recursive one;
called through a pointer to it.
Yes, modern compilers will (depending on various configuration options) automatically choose to inline functions, even if they're in the source (not header) file. Using the inline directive can give a hint.
Aside from your main point (what amount of placing inline instructions in code is useful as of compilers today), keep in mind that inline functions are just a hint to the compiler, and are not necessarily being compiled as inline.
In short, yes, compilers will decide whether or not your function becomes inline. You can check this question:
Does the compiler decide when to inline my functions (in C++)?
C++ ISO standard says, that:
"A function defined within a class definition is an inline function."
Are there any compilers that IGNORE this rule?
(please, do not mistake inline with inlineD - my question is if there is a compiler, that wont put there that inline suggestion that it should)
You seem to be misunderstanding what "inline" means. It doesn't mean functions will automatically be inlined; according to 7.1.2-2 it indicates that inline substitution is to be preferred.
Therefore, you can't tell whether a function is labeled inline or not from the code, since the compiler is free to decide one way or another. It's just a compiler hint.
The standard says that all compilers can ignore inline requests, whether implicit or explicit. Whether or not they do so will nornally depend on whether the function can practically be inlined - for example recursive functions cannot be.
Edit: Just to clarify - the questioner is ignoring this, from the previous para in the standard to that he quoted from:
An implementation is not required to
perform this inline substitution at
the point of call
I suspect your test is flawed. You can't test with only one such file whether the compiler ignores the inline specifier or not.
You need to include the header containing the inline function definition and include it into multiple implementation files that are then linked together. If you get linker errors about multiple defined instances of that functions, then the compiler is ignoring the inline specifier regarding its most important property: Allowing it to be defined multiple times across the entire program while still retaining the same address for it and its local static variables.
What your test probably checks is whether or not the compiler inlines the call to the function, which is actually only a hint to the compiler and only a small of many other more important consequences of the inline specifier. If the compiler does not not inline a call to the function, it is fine doing so. The standard does not require it to do anything in this matter.
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.
Compiler's usually inline based on the number of calls to the function, the number of pseudo-instructions in the function, and a bunch of other things. Take a look at the GCC documentation on optimization options for an idea of how it does things. Basically, the inline keyword is just a hint that bumps up the likelihood that the compiler will inline. The actual decision to inline is usually complex.