Thread: inline keyword and function prototype

Well, you certainly are trying to get to the very bottom of this, aren't you?

Before I get to your specifics, the keyword 'inline' is a hint, not a directive, so the compiler is free to and will decide on it's own what to emit as inline code. This even applies to the various "force inline" alternatives (they're just louder hints).

There is, however, another meaning to the inline keyword. If you write a function definition in a header file (which is usually also it's declaration in that case) but do not declare the function inline, then every translation unit processed will have a duplicate of that function which will (usually) give a warning or error of a duplicate symbol (or some such text). The linker might resolve that, after the warning, by ignoring the duplicates. In this context the inline keyword is intended to inform the compiler/linker (the linker is really the target here) that this is written inline (where, in this context, the word inline means a function definition in a header), and to 'ignore' or 'automatically resolve' the duplicates without warning.

For the most part the rest of your observations deal with the subject of storage class. When you don't specify a storage class like static, the compiler will make the choice, inferring from context. When you explicitly declare the static storage class, you're overriding the nature of "where it is stored". Functions declared inline aren't really stored if they are actually emitted inline, and even if the compiler does decide to ignore your optimization hint/request, it considers the function it creates with a default storage class appropriate for the context. When you declare static you've taken control of that, so the behavior changes.

As to another point (was it 4 or 5?), the order in which an inline appears matters because C (and C++) are processed by what is known as single pass parsers/compilers. Some languages use dual (or more) passes to read your code, and can, essentially, "look" backwards and forwards through your code. C and C++ don't. Everything is 'considered' by the compiler in one pass, from top to bottom. This is essentially why you must declare functions you intend to call if you don't write the definitions before the call. With that in mind it should be clear that separating a declaration with the inline keyword applied from the definition of that function would obfuscate the nature of inlining. In order to emit the code inline, the compiler, limited to one pass reading through your code, must first have read the definition in order to be able to emit that code as inline assembler output. In other words, if you've declared a function to be inline, you want the compiler to emit inline assembler, then at the moment you call that function you're asking the compiler to do that right now, at that point where the text of the call appears. If the definition hasn't been read yet, it can't possibly emit that code inline - it would have to resort to that being a function call (and may well convince it to do so), while the definition, appearing later, fulfills the linker's need to know the full code for that function call.

As to 6, yes, the inline keyword applied to the declaration already informs the compiler, and I don't see where it would require the keyword to be repeated later, because it isn't really changing anything otherwise significant like the return type, parameter list or storage class. I assume you're expecting inline should be a matching token of the declaration and definition, but in the details of this (which I happily don't read all the time, because I'm not a language lawyer), the return type, storage class, parameters and even the function's name are all very significant in the identification of the function, and how it is to be called. The inline keyword is not any one of those things, but a kind of decorative hint to the compiler (and a signal to the linker) regarding where it is (to avoid duplicate symbol warnings/errors). In reality, you make just as significant (or insignificant) hint to the compiler that it should consider emitting the code inline by where the function is and how short it is. You've hinted the example above. If the function definition is short and appears before it is called, the compiler is going to consider that as a candidate for emitting the assembler as an inline and not a function call, without using the inline keyword.

This may also help to know:

In C++ this is a bit more common because short function definitions frequently appear in the headers, inside a struct or class. In that situation, because the definition is inside the struct or class declaration, the compiler treats all of those little member functions as having the inline keyword, and that is with respect to both meanings. Those functions, without the inline keyword used, are assumed to be inlines because of where they are, even to the extent of the linker suppressed from complaining about them being duplicate symbols when they are emitted as function calls.