8

Well, there is no guarantee by the standard that inline functions are actually inlined; one must use macros to have 100 % guarantee. The compiler always decides which function is or is not inlined based on its own rules irrespective of the inline keyword.

Then when will the inline keyword actually have some effect to what the compiler does when using modern compilers such as the recent version of GCC?

Improve this question
7
  • 6
    Macros are not a 100% guarantee. A compiler is free to factor out duplicate code (from multiple expansions of a macro) into multiple calls to the same copy of the code (essentially a function call). Commented Dec 14, 2014 at 0:50
  • In C++ it's effective when you need to worry about ODR... probably similar in C. Commented Dec 14, 2014 at 0:53
  • 1
    @R..: Macros are always substituted at the usage site by the preprocessor. After that, they're subject to the same optimizations as any other code placed directly inside the function. Commented Dec 14, 2014 at 0:56
  • 2
    You should certainly review Is inline without static or extern ever useful in C99?, and you might review extern inline too. Note that it is worth making even non-inline functions static whenever possible; the compiler may well optimize them into inline code if it makes sense, but it can only do that if it knows the function will not be called from outside the current source file, which means the function must be static. Commented Dec 14, 2014 at 0:59
  • 2
    @JonathanLeffler Small nitpick: The compiler does inline non-static functions, it just has to leave a copy for external callers around (increasing code size). Whether this affects inlining heuristics I do not know. There are other good reasons to make helper functions static though (less pollution of the global namespace, and hence the ability to use shorter, nicer names). Commented Dec 14, 2014 at 1:05

2 Answers 2

Reset to default
5

It has a semantic effect. To simplify, a function marked inline may be defined multiple times in one program — though all definitions must be equivalent to each other — so presence of inline is required for correctness when including the function definition in headers (which is, in turn, makes the definition visible so the compiler can inline it without LTO).

Other than that, for inlining-the-optimization, "never" is a perfectly safe approximation. It probably has some effect in some compilers, but nothing worth losing sleep over, especially not without actual hard data. For example, in the following code, using Clang 3.0 or GCC 4.7, main contains the same code whether work is marked inline or not. The only difference is whether work remains as stand-alone function for other translation units to link to, or is removed.

void work(double *a, double *b) { if (*b > *a) *a = *b; } void maxArray(double* x, double* y) { for (int i = 0; i < 65536; i++) { //if (y[i] > x[i]) x[i] = y[i]; work(x+i, y+i); } }
Improve this answer
Sign up to request clarification or add additional context in comments.

7 Comments

十1 for the one semantic effect, but you should elaborate on it a little. inline does not exempt you from the "one definition rule". There still must be exactly one external definition, and if it does not match the inline definition, the result is undefined.
@R.. Yes, I gloss over many details, some of which I'm probably not even aware of. I'll add in some weasel words.
The "one definition rule" is a C++ term, and C++ semantics of inline don't match those of C. C always needs one external definition, even if there's an inline definition in every translation unit, and does allow inline definitions that have different bodies (and it is unspecified which of those gets called).
@hvd: I don't think C always needs an external definition of an inline function. If you use a header to define the function as static inline ..., you won't get any linking errors as long as that header is used everywhere the function is used.
@JonathanLeffler: With static, inline is semantically a no-op, so the non-static case is the interesting one. On the other hand, I agree static is what you usually want. External inline semantics are too confusing, especially with the incompatible GNU semantics that are default in some GCC profiles. :(
|
1

If you want to control inlining, stick to whatever pragmas or attributes your compiler provides with which to control that behaviour. For example __attribute__((always_inline)) on GCC and similar compilers. As you've mentioned, the inline keyword is often ignored depending on optimization settings, etc.

Improve this answer

Comments