I always try to keep implementation outside of headers, so for templates and inlined functions, I usually do something like this
// File.h
inline bool foo()
#include "File.hpp"
// File.hpp
inline bool foo()
{
return 1;
}
My question is, what does the C++ specification have to say about repeating the inline keyword for the actual implementation of the function? (as shown in this example)
I don't really want to do that as it gets messy with lots and lots of functions, and while my compiler doesn't complain, I wonder if the compiler still accepts the inline hint.
Anyone know?
I tend to put inline as far from the interface as possible since it is an implementation detail and not part of the interface. Hence: omit the first inline in the declaration. And only attach it to the function definition. For the inclusion of an hpp compiler scopes are irrelevant in respect to inline since the files are treated as concatenated.
See also http://www.parashift.com/c++-faq/where-to-put-inline-keyword.html for a more detailed explanation.
It's OK, but putting inline in the source file is even less of a hint, because the sources aren't generally visible to other translation units. If you implement the function outside the header, the compiler will probably not be able to inline it anyways.
The only practical use of inline, in my opinion, is to prevent multiple definition of functions defined in the header.
Related
My goal is to reduce the function call overhead for some of the methods I have defined in my class. These methods are used by other methods and they are not intended to be publicly accessed. I have done some research but could not put together the information I found. Is it sufficient to specify the method inline in the definition and not in the declaration? Is it a bad technique if the method is publicly accessible?
file.h
class Foo
{
/* ... */
public:
bool bar ( int par );
void zar ( void );
/* ... */
};
file.cpp
inline bool Foo::bar ( int par )
{
/* ... */
}
void Foo::zar ( void )
{
/* ... */
if ( bar(10) )
{
/* ... */
}
/* ... */
}
Is the usage of inline specifier in this example a good technique?
The code is operational but I want to understand the unforeseeable consequences. Whether this is the correct usage or not.
inline has officially almost nothing to do with whether the function will be inlined or not.
Its official purpose is to allow multiple identical definitions to exist without violating the ODR (one-definition) rule. Meaning you can put the definition into a header, include it from multiple .cpp files - translation units - and the linker will not complain about multiple definitions, instead it will pick one. Therefore you must ensure the definitions are identical (i.e no two "unrelated" inline functions with the same name in separate .cpp files - they should have been marked static instead), otherwise good luck debugging the calls.
If you want to force inlining, there is no standard tool for that, but all compilers support directives to do so e.g. __attribute__((always_inline)) for g++/clang.
But if you want to rely on the compiler to use its judgement, you can help it by ensuring the definition is available at the call site. This can be achived by either putting the definitions into headers or enabling link-time optimizations. The former means to put the definition inside the class or somewhere after the class definition, in that case mark them inline. Just note that this means that any change in the implementation will require recompilation of all translation units which include that header.
Is it sufficient to specify the method inline in the definition and not in the declaration? Is it a bad technique if the method is publicly accessible?
Not guaranteed but yes, if the compiler believes it is beneficial to inline the call, it has all the information necessary to do so. Bad technique? I would say that is completely orthogonal issue, caller should not care about the "calling convention". Make methods public based on API design alone.
Is the usage of inline specifier in this example a good technique?
No, it is useless to mark function inline inside a single translation unit. Because it is not visible to other units and it is already visible to the original unit. I would say that it is even dangerous to do so exactly due to my second paragraph, if someone else comes and implements inline Foo:bar in file2.cpp, the linker will silently most likely pick a single definition for all non-inlined calls but calls inside file.cpp which were inlined will call file::bar definition - as I said, good luck tracking those issues.
inline is mostly a historical artifact similar to register, a recommendation to the compiler from a time when compilers were too dumb to make the call what to inline and when (1990s - early 2000s).
From 7.1.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.
Nowadays, there is nearly no valid situation where you should be using it, save for some special cases of manual optimization and such. In general, you shouldn't be using it at all.
It's an optimization for execution speed over program size. Historically you would use inline for small functions to reduce the function call overhead. People had this nasty habit of using function-like macros for that purpose and inline was supposed to put a stop to that.
For inline to work as expected, the function definition needs to be in the same translation unit (.cpp file and all headers it includes) as the caller. Which typically means that it needs to be placed in a header. It's not necessarily a bad ting to inline public methods, particularly simple setters/getters, but you shouldn't need to.
EDIT:
Note that inline should be accompanied with static to ensure that multiple definitions of the function aren't possible. This is required for the one definition rule (7.1.2):
An implementation is not required to perform this inline substitution at the point of call; however, even if this inline substitution is omitted, the other rules
for inline functions defined by 7.1.2 shall still be respected.
An inline function shall be defined in every translation unit in which it is odr-used and shall have exactly
the same definition in every case
An inline function shall be defined in every translation unit in which it is odr-used.
(Similarly in C, if you declare an inline function without static and don't define the function in the same translation unit, you invoke undefined behavior (6.7.4/7).)
I defined a class in header file and implemented its function in same header file. I didn't put inline keyword with function definition because I think compiler will regard it as a inline function by default -- but inline is only a hint to compiler, right? What if compiler doesn't regard it as inline function because of its length? I never get error message 'multiple definitions' in reality.
struct tmp {
void print() {
...(very long)
}
};
I didn't put inline keyword with function definition because I think compiler will regard it as a inline function by default
Yes, member functions defined in the body of a class are implicitly inline. The keyword is not necessary.
inline is only a hint to compiler, right? What if compiler doesn't regard it as inline function because of its length?
Yes, sort of. Actually, the inline keyword has two meanings.
The first one is the one you are thinking of, the one that hints to the optimizer to inline the code in the function body at the call site. As you said, this is just a hint—the optimizer is free to ignore this request if it determines that it would be a performance pessimization to do so (or if it is unable to inline for some other technical reason). This meaning of the inline keyword is arguably obsolete. All optimizing compilers nowadays ignore the inline keyword because their authors consider their heuristics to be smarter than the programmer. This is almost always the case, making it rather pointless to try and second-guess the optimizer by marking your functions inline.
The second meaning of the inline keyword is to relax the one-definition rule (ODR), making it legal for there to be multiple definitions of the same function visible to the linker. (Although the behavior of the linker under such circumstances is an implementation detail, most of them will just arbitrarily pick one of the definitions. Which of course only works out well if they are all the same.) This meaning of the inline keyword is still very important, and explains why it is still used today in code.
This is the meaning that your code is benefitting from. Since member functions defined in the body of a class are implicitly marked inline, you do not get multiply-defined symbol errors from the linker.
If you had defined the function in the header file but not within the class definition—in other words, if you had done this:
struct tmp {
void print();
};
void tmp::print()
{ ... }
then you would start getting the multiply-defined symbol errors as soon as that header file was included in two or more compilands (i.e., translation units). This is where you would need to add the inline keyword on the function's definition, not because you want the compiler to "inline" it, but because you want to exempt yourself from the ODR.
EDIT #Leon (below) stated that my answer (reproduced below) was INCORRECT. The correct answer is described here - in short, if the compiler decides to not make a function inline, it still puts it in the object module. But the linker will then pick one of the (potentially many) copies in the different modules and discard all the others.
You are right: you won't get the "multiple definition" error because every time the compiler decides to not put a function inline, it makes the function static within the current module. That means that you could have a large number of copies of your large function littered through your code.
I have the following class defined in a foo.h header file
class Foo {
public:
inline int Method();
};
inline int Foo::Method() { // Implementation }
I would like now to move the implementation to a foo.cpp file. To this end, I have to remove the inline keyword and move the implementation of the method to a foo.cpp file like this
#include `foo.h`
inline int Foo::Method() { // Implementation }
I have two questions:
Is my statement about the removal of the inline keyword correct? Should it be necessarily removed?
How typically the removal of the inline keyword affect the performance (practically all my methods are inlined)?
Thank you very much in advance.
If you moved the function definition from a header to a cpp file, you MUST remove the inline keyword all all locations for that function. With older linkers it might make things slightly slower, but with modern linkers you should notice no real difference in performance.*
There are certain cases where a public member function can be inline, but that's just a bad idea. Don't do it. Arguments can be made for marking certain private member functions as inline, but in reality what you really want in those to be __attribute__((always_inline)) or __forceinline
*In extremely rare cases it will make a difference, but 99% of the time it won't, and 99.9% of what's left you don't care. If measurements show you hit that one-in-ten-thousand, you can use the aformentioned __forceinline.
Keyword inline is redundant in the class. It is implied if you have a function body.
In the implementation file it is also fairly redundant.
The only use of it is if you define a free function in a header (or a member function outside the class, but in the header) to avoid multiple bodies.
Optimization-wise on mist modern compilers it's even more redundant, they inline anything in sight without question anyway, or ignore your keyword at will.
The inline usage must be consistent! From 7.1.2p4:
An inline function shall be defined in every translation unit in which it is odr-used and shall have exactly the same definition in every case (3.2). [ Note: A call to the inline function may be encountered before its definition appears in the translation unit. —end note ] If the definition of a function appears in a translation unit before its first declaration as inline, the program is ill-formed. If a function with external linkage is
declared inline in one translation unit, it shall be declared inline in all translation units in which it appears; no diagnostic is required. ...
You, and the people here giving advice about small functions, are looking at inline the old-fashioned way.
inline used to mean "I want this code to run quickly, so whenever I call this function, I want you to expand it in-place to avoid the overhead of a function call."
That's a really good optimization. It's so good, in fact, that the compiler will eagerly do it even if you don't specify inline.
The compiler is also free to not expand your inline functions. So you really don't have to worry about how it will affect performance, because the compiler can and will ignore inline if you use it in a stupid way.
In fact, compilers today almost always ignore your use of inline, and just do whatever they think is best.
So, knowing that, why do people still use inline?
There's only one reason to use inline nowadays, and that's to work around the One Definition Rule (ODR).
In C/C++, you're only allowed to define a function once. If you do this:
int foo() { /* do something */ }
int foo() { /* do something else */ }
the compiler will complain that you've defined the same function twice.
That looks like a silly example, but it's particularly easy to do something like that when you're using #include - if you defined your function in a header, and you #include the same header twice, this is exactly what you're doing.
Thankfully, inline has another use which is still valid today: if you mark a function as inline, it forces the compiler to silence ODR issues, making it possible to define your function in a header.
In other words, inline now means "I want to define this function in a header."
When you look at it that way, it should be clear that you should remove the inline when moving the function into a cpp file.
For interest sake, there's a couple places where functions are implicitly made inline. One of them is in class member functions:
struct Foo {
void bar() { /* do something */ }
};
I've seen people mark functions like this inline, but that's completely redundant. The compiler does it anyway; there's no need to worry about ODR, and there's no performance to be gained.
The other place is in templates. Since templates have to be defined in headers, they're exempt from the ODR, and inlineing them is redundant.
If the function isn't TINY (or takes several arguments, but doesn't do much, such as a constructor or similar, that takes a bunch of things, and just copies it to somewhere inside the class), inlining it will have little impact on performance in the first place. Setters and getters are usually good candidates to inline, since they (typically) just copy data from one place to another, and can easily be done where the call takes place.
As others have said, it's a "please compiler, if I may ask you kindly, consider inlining this function" - it's not a "make this function inline". The compiler, on the other hand, will often inline functions REGARDLESS of whether there is an inline keyword. It looks at the size of the function, the number of calls and how much larger the code gets from inlining.
If you move the function to "foo.cpp", it will ONLY get inline inside the "foo.cpp" compile unit (typically, compile unit = source file).
That is unless you have a compiler capable of "whole program optimization" or similar tricks, and enable that feature - this basically means that instead of producing a ready to link object file with machine code, the compiler produces a "parsed, but not completely translated to machine instructions" object file. Then, when it comes to finally putting the executable (or shared library) toegether, the compiler/linker will produce one large lump of machine code from the "halfway" code. Both MS and GCC do support this, but I don't know how well it works for large projects.
Edit:
As per Mooing Duck's comment: An inline function doesn't make a real function name in the object file, so the linker may also give errors for unresolved symbol int Foo::Method() [or some wording to that extent].
End edit.
If performance is critical, you should measure the current code's performance, then make your changes, and measure it again. If it's significantly different, you'll have your answer. If it's faster (because of less inlining leading to more cache-hit rate for other bits of code, for example), then that's good. If it's slower, you'll have to put back (some of) the functions into the header file. Or live with it being slower... Or find some other way of making it faster again... The choices are yours (and, if you work in a group, some other people may have a say in the final decision, of course). It's almost impossible for anyone to say for SURE which way it will go without at the very least understanding the whole programs architecture and what goes on in the class - which, given the name "foo.cpp" in the post is probably not the REAL code...
It may be confusing, but you should not think of the purpose of inline to make the compiler inline a function. (Modern compilers are way smarter than you in regards to when a function should be inlined or not anyway).
No, the real purpose of inline is to tell the linker to not worry about multiple definitions of the function. If you put the definition of a (non-member) function in a header, you should mark it inline to avoid linker errors.
2. How typically the removal of the inline keyword affect the performance (practically all my methods are inlined)?
The inline keyword tells the compiler to take the implementation code of that function and put it in place of the function call. This reduces the number of function calls on the stack and if used correctly, can improve the performance of your program.
The inline keyword should only be used with small functions. Get and Set functions are good examples. They set the value of one variable or return the value of one variable.
If you make a function with a lot of code inline, it can increase the size of your code by a lot (depending on the size of the function code and how many times that function is used) and actually DECREASE the performance of your program.
I need to define inline functions to improve performance of my code. At the moment declaration of functions are in .h file and definitions are in .cpp file. I added inline keyword at the front of each declaration of functions but I am getting link error. Is possible to separate declaration and definition of inline functions ?
You can separate the declaration and definition fine, but that definition must be available in every translation unit that uses the function, e.g.:
#include <iostream>
inline void foo();
int main() {
foo();
}
inline void foo() {
std::cout << "Hi\n";
}
is perfectly legal and correct.
The exact quote from n3290 § 7.1.2.4 is:
An inline function shall be defined in every translation unit in which it is odr-used and shall have exactly
the same definition in every case (3.2). [ Note: A call to the inline function may be encountered before its
definition appears in the translation unit. —end note ]
Where § 3.2 basically says that it has to be identical everywhere, even overload resolutions etc.
Are you absolutely sure that making your functions 'inline' would improve your performance? I am pretty sure it will not.
The compiler is able to inline some function calls if and only if it can see the body of the inlined functions. So you need to include the body of the function as well, but if do it, you do not need to annotate your function with 'inline' because the compiler only needs the body of the function -- not your 'inline' keyword. Compilers nowadays are smart and know without your hints whether and when to inline functions. And inlining does not necessarily increase your program's performance, and it is likely to increase your executable's size.
See this article by Herb Sutter. He argues that keyword "inline" has no meaning in C++. But I disagree with him. Keyword "inline" makes one difference: you can specify the body of the inline function more than once in the program (provided that it is exactly the same definition each time) -- this is useful when putting function bodies in headers (if you need this for any reason).
Yes, but you have to put the implementation in the header file. That is because in order to be inlined, the definition has to be known, when including the header.
If you do so, modern compilers will automatically inline the function even without the inline keyword.
Use a separate "implementation header" that you will still include everywhere?
You are need specify only once prototype or realization. Both is eligible.
By definition, inline functions must be known at compile time.
If you want to define them in a separate .h file, you can use a
#pragma once
trick to only insert their definition once.
I have found that in some embedded toolchains, the #inline keyword is not allowed in the function declaration. You can specify it in the definition, but (as stated above) many compilers ignore the keyword anyway.
I tend to put the body of smaller functions right into the header file foo.h, not into the separate implementation file foo.cc, because then the compiler can always see those functions completely and decide to inline them.
Example:
// File "foo.h":
struct Foo {
// ...
int GetCount() const { return count_; }
};
Now any code that uses Foo sees the whole GetCount implementation and can decide to inline it.
Is that good practice? If so, do you put slightly larger function definitions into the header file as well?
Modern compilers have link time optimization, so it is not necessary anymore to have the code available in the header for a function to get inlined. Hence I would say it would be a better practice to just mark the declaration as inline, but put the definition in the cpp.
It's good practice, yes. I think, practically speaking, for this scenario, as long as you understand the behaviors, then you can feel free to inline your functions as you wish. Note that the compiler will make the ultimate decision about inlining though.