14

I understand you can use the inline keyword or just put a method in a class declaration ala short ctor or a getter method, but does the compiler make the final decision on when to inline my methods?

For instance:

inline void Foo::vLongBar() { //several function calls and lines of code }

Will the compiler ignore my inline declaration if it thinks it will make my code inefficient?

As a side issue, if I have a getter method declared outside my class like this:

void Foo::bar() { std::cout << "baz"; }

Will the compiler inline this under the covers?

Improve this question
0

9 Answers 9

Reset to default
17

Yes, the final decision of whether or not to inline your code lies in the C++ compiler. The inline keyword is a suggestion, not a requirement.

Here are some details as to how this decision is processed in the Microsoft C++ Compiler

Improve this answer
Sign up to request clarification or add additional context in comments.

4 Comments

Could you elaborate on why this is? I thought the point of C++ is to give the programmer enough rope to hang hisself, but this seems restrictive. Is there a good reason?
@Hooked, take a look at the link I posted. It goes into a bit of detail as to why this is not always a good thing. First item that comes to my mind is head recursive functions.
The standard states that even __forceinline does not end the debate, the compiler still has the final word. I can understand when inlining would be inappropriate, but if a programmer/profiler decides to over ride the compiler, what are his options? That link does not detail the rationale behind letting the compiler decide.
It may simply be impossible to inline a given function. That said, it should be noted that some compilers at least still give you the way to override the final decision - e.g. __forceinline in VC++. This still doesn't let you inline functions that cannot possibly be inlined, but it will override compiler's cost/benefit analysis otherwise.
12

Whether or not a fiunction is inlined is, at the end of the day, entirely up to the compiler. Typically, the more complex a function is in terms of flow, the less likely the compiler is to inline it. and some functions, such as recursive ones, simply cannot be inlined.

The major reason for not inlining a function is that it would greatly increase the overall size of the code, preventing iot from being held in the processor's cache. This would in fact be a pessimisation, rather than an optimisation.

As to letting the programmer decide to shoot himself in the foot, or elsewhere, you can inline the function yourself - write the code that would have gone in the function at what would have been the function's call site.

Improve this answer

8 Comments

See my comment on JaredPar's answer, please.
Recursive functions can be inlined into specified depth :)
How does the compiler know what the depth wiill be at compile time?
@Neil Butterworth: I presume that the compiler can see how many iterations there are if the number of iterations is constant or a constexpr.
From the msdn pages, it appears that inline recursion must expand more times than may actually be necessary. It looks to be likely to be a pessimation (in terms of code size) more times than an optimisation (in terms of performance). Oh, amd BTW, could you stop putting a smiley after every comment you make here? You've even got one after your answer!
|
5

As others have noted, the inline keyword is merely a suggestion to the compiler to inline the code. Since the compiler will routinely inline code that hasn't been marked with inline, and not inline code that has, the keyword seems just as redundant as register or (pre-C++0x) auto.

However, there is one other thing that the inline keyword effects: It changes the linkage of the function from external (the default for functions) to inline. Inline linkage allows each compilation unit to contain it's own copy of the object code, and has the linker remove redundant copies from the final executable. If that reminds you of templates, yes, templates also use inline linkage.

Improve this answer

Comments

4

As many have already posted, the final decision is always up to the compiler, even if you can give firm hints such as forceinline.
Part of the rationale is that inlining is not an automatic "go faster" switch. Too much inlining can make your code much larger, and may interfere with other optimizations. See The C++ FAQ Lite about inline functions and performance.

Improve this answer

1 Comment

Thanks for the link. I've read most of the Faq lite, but not this.
3

Yes, the compiler has the final decision. In VS you can even inline recursive functions into specified depth ;)

#pragma inline_depth( [0... 255] )
Improve this answer

Comments

3

Just to add my 5 cents ...

I found this Guru of Week article about inlining very useful.

As far as I remember I read somewhere that even a linker might do inlining, when it links the object files and finds that the code being linked can be inlined.

Improve this answer

Comments

2

As a side issue, if I have a getter method declared outside my class like this:

void Foo::bar() { std::cout << "baz"; }

Will the compiler inline this under the covers?

It depends. It can for all callers in the same translation unit (the .cpp file and all of its #included definitions). But it still has to compile a non-inlined version because there may be callers of that function outside the translation unit. You can potentially see this at work (if your compiler actually can do it) at high optimization levels. (In particular: compare what happens when you #include all your .cpp files in one .cpp vs. the typical layout. With all definitions in one translation unit the opportunities for such inlining increase dramatically.)

Improve this answer

2 Comments

Oh, I did not know that. I am not aware what exactly the linker does (I've been spoiled with my fancy IDE's, I haven't ever had to compile by command line and go through the process).
Understanding how the linker works ought to be fairly transparent (you shouldn't need to know it to get work done). But it ends up being particularly important to learn about it in C++, because so many language constructs don't quite behave the way you'd expect if you don't know what is visible to the linker and what isn't. inline is the biggest one, but the difference between what goes in a .h and .cpp, what static means, where templates can go ... these all come up. Unfortunately linking can really trip you up in C++ if you don't have a basic understanding of it.
1

As per my knowledge, compiler will automatically make a function you declared inline (or wrote inside a class declaration) non -inline if it finds a loop like for, while etc. This is one example where compiler has the last say in inline functions.

Improve this answer

3 Comments

I...do you have any sources to back up that claim?
A loop? Why a loop? Don't you mean recursion?
It's implementation-specific. The Standard doesn't say anything about when a function might be not inlined; only that implementation has the final decision.
1

If you really, positively, absolutely, without fail NEED to inline the code, there is always the macro. C has supported these for years and because they are just text replacement prior to compilation, they really, truly, inline whatever you write.

That's why the 'inline' keyword (and even, in some cases, the forced variants) can afford to not have a standard way of forcing it - you can always just write a macro.

That said, the inline keyword is often better, because the compiler quite often knows if making a function inline makes sense or not, and because the inline can interact with the rest of the compiler optimizations.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.