GNU C ++编译器（（GCC）5.2.0）本身是否擅长“内联”？

Question

I'm not asking why or when I should use inline in some code.

I use inline where I think it's usual (like in get/set functions). I read on stack some unusual example where inline sounds necessary. I'm not sure that I'll recognize a such situation in my code... I mean, until I get an issue...

So I wonder if for usual cases the compiler handles that as well as I do, maybe even better...

The reason why I would like to avoid inline , is to avoid having to implement in the headers ... About that a question pop in my mind:

is the compiler (I always consider the GCC compiler in my question) able to inline a function not implemented in the header ?

nb : I don't know if there is some internal changes about inline in C++14.

Answer 1

First of all inlining something ie requiring inline substitution of the function body at the point of call doesn't mean that the implementation is constrained to do so :

7.1.2 Function specifiers

2 A function declaration (8.3.5, 9.3, 11.3) with an inline specifier declares an inline function. 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. 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.

This alone should give a taste that it's a fuzzy heuristic to rely on compiler optimizations (or that it matters doing so) regarding this topic. For example we know that the compiler has a hard time inlining function pointer calls but this is not of much importance.

There are some examples of language constructs that the Standard mandates to be inlined and this not a matter of being a good compiler but a compliant one.

Function Call operators of closure types

5.1.2

5 The closure type for a non-generic lambda-expression has a public inline function call operator (...) For a generic lambda, the closure type has a public inline function call operator member template (...)

constexpr functions

7.1.5

2 (...) constexpr functions and constexpr constructors are implicitly inline (7.1.2).

Deleted functions

8.4.3

A deleted function is implicitly inline. [ Note: The one-definition rule (3.2) applies to deleted definitions. — end note ] A deleted definition of a function shall be the first declaration of the function or, for an explicit specialization of a function template, the first declaration of that specialization.

Other examples are member functions defined inside the class definition and a function defined in a friend declaration of a class. Inlining is not the best choice in every case (can increase program size) so for performance critical section I'd suggest benchmarking and deciding yourself; after all Do inline functions improve performance?

Answer 2

The compiler can inline a function used in the same file (technically, "compilation unit") but not when compiling different files, since it doesn't have the source. That's why inline functions should be placed in the header file.

Answer 3

Without some kind of example code, it's VERY hard to say for sure what the compiler will do (even WITH code, it can be pretty darn difficult).

Generally speaking, if the function is small, the compiler will inline functions that have their source code available during compilation (and others if you enable lto (link time optimisation). If you expect to be able to compile a function into an object file and get the function inlined, then you HAVE to use lto.

A function that is large and static, called only once will also be inlined in most cases.

The problem comes when you have several calls and the function is "more than tiny in size" - in other words more than 3-4 lines long. Then the compiler has to balance between inlining and bloating the code, and not inlining and the cost of calls. This is a very difficult balance to get right. Profile-driven optimisation can help a lot here, but in general, the compiler will MOSTLY get it right, but not at all guaranteed - if in doubt (and it's important), use a benchmark of your application, and measure whether it gets better with a force inline attribute.