views:

352

answers:

9

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?

+13  A: 

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

JaredPar
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
@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.
JaredPar
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.
Hooked
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.
Pavel Minaev
+7  A: 

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.

anon
See my comment on JaredPar's answer, please.
Hooked
Recursive functions can be inlined into specified depth :)
AraK
How does the compiler know what the depth wiill be at compile time?
anon
see my answer ;)
AraK
@Neil Butterworth: I presume that the compiler can see how many iterations there are if the number of iterations is constant or a constexpr.
the_drow
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!
anon
@the_drow Actually, no it cannot. For example, if I have a recursive expression evaluator and I pass it some cobnst string as an expression, the only way the compiler can work out the required depth is by evaluating the expression. This is a variation of the Halting Problem.
anon
@AaraK It means I never know if I should take your comments seriously or not.
anon
+1  A: 

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.

Ganesh R.
I...do you have any sources to back up that claim?
Hooked
A loop? Why a loop? Don't you mean recursion?
Vilx-
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.
Pavel Minaev
+1  A: 

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

#pragma inline_depth( [0... 255] )
AraK
+3  A: 
MadKeithV
Thanks for the link. I've read most of the Faq lite, but not this.
Hooked
+1  A: 

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.)

quark
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).
Hooked
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.
quark
+2  A: 

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.

+2  A: 

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.

Regards,
Ovanes

ovanes
+1  A: 

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.

Michael Kohne