Question

I have searched and have been unable to verify how the GCC compiler will handle inlining getters and setters when declaration is in .h file and definition is in .cpp file.

Most seem to say that GCC can’t see across these source file barriers and won’t be able to inline these at all, while others disagree. I have looked at the documentation and I can’t find the answer there either. Did I miss it?

I do realize that inlining is a choice made by the compiler and is not always guaranteed, but assuming optimal situations, is it at least possible?

Answer 1

(What you really meant to ask is about the situation where the definition is in a different .cpp file to the one you’re currently compiling, and then linked in later. The compiler doesn’t care about .hpp or .cpp, but about translation units.)

Anyway, on http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html, scroll down to “flno”:

This option runs the standard link-time optimizer.
[…]
The first two invocations to GCC will save a bytecode representation of GIMPLE into special ELF sections inside foo.o and bar.o. The final invocation will read the GIMPLE bytecode from foo.o and bar.o, merge the two files into a single internal image, and compile the result as usual. Since both foo.o and bar.o are merged into a single image, this causes all the inter-procedural analyses and optimizations in GCC to work across the two files as if they were a single one. This means, for example, that the inliner will be able to inline functions in bar.o into functions in foo.o and vice-versa.

So, yes, it’s possible to optimise inlines across module boundaries.

However, C++ still makes its requirement of:

An inline function shall be defined in every translation unit in which it is used. [3.2/3, C++03]

So in fact you may not write your code to take advantage of this if you used the inline keyword; you are instead reliant on the linker “just deciding” to inline your function if it sees fit. So it’s not an option that’s going to allow you to move your code around.

Remember, writing inline in your code does not have a one-to-one relationship with a function actually getting physically inlined; it’s only a hint to the compiler (or linker, if you have the above mentioned link-time optimisations turned on).