Understanging the use of inline funtions

[John Fine]

Tobias Föhst wrote:
> Now I found different statements in discussions and online artciles
> saying
> 1. The inline keyword is just a hint. The compiler decides if it uses
> it or not.
>   
True.  Compared to other C++ compilers, GCC gives the programmer more 
control over whether things are inlined, including more often simply 
obeying the inline keyword.  But in the language standard the inline 
keyword is just a hint.  Whether GCC obeys that hint depends on a 
variety of switches and other factors.

> 2. C'tors and d'tors are always automatically inlined.
>   

Either that is missing important context or it is nonsense.

> 3. GCC does not use the inline keyword but has its own ideas about
> inlining function calls.
>   
The inline keyword is usually one of many factors in deciding whether a 
function is inlined.

> 4. GCC does inlining not below -O3 or the explizit activation using
> -finline-functions
>   
I'm not sure.  I think the decision rules are more complex and depend on 
more switches and there would be exceptions to a statement as simple as 
the above.

> 4. Everything defined in a header file is inlined.
>   
Nonsense.

> inline_test.h:6: warning: inline function ‘int Foo::GetX() const’ used
> but never defined
>
> Seems perfectly correct to me, because the definition of GetX is not
> known at a point its code should be inlined. It was alreay compiled
> into object code when compiling inline_test.cpp.
> On the other hand, that would mean, that the compiler _always_ has to
> obey to the inline keyword if the definition is given in a cpp file.
>   
False.

I'm not sure what the standard says about the inline keyword on the 
DECLARATION of a function which is used but not defined.  The Intel 
compiler I normally use has an option to generate a warning in that 
case.  I haven't figured out how to make it convert that particular 
warning to an error.  I would if I knew how.  But a warning is better 
than silent.

As a professional programmer working in a large project with very 
tangled includes, I find:
1) It is very hard to avoid including the declarations of a lot of 
functions into a lot of compiles in which those functions are never 
called and in which you would not want the definitions included.
2) There are a lot of those functions for which you want to always give 
the compiler the ability and the hint to inline.

It is a very useful language feature to be able to put the inline 
keyword on the declaration of such functions, expecting that the 
compiler won't care about that keyword if the function is never called, 
but will take that keyword as a request for a diagnostic message in case 
that function is called but not defined.

But if that function is in fact both defined and called, the compiler is 
not (nor should it be) forced to inline that function.  It should be no 
different in that respect from a function where the inline keyword is 
only on the definition.  Various switches and other factors determine 
whether the compiler takes the hint.

I'm not sure how close the language standard nor any particular compiler 
allows to what I consider best behavior on the inline keyword for 
functions called but not defined.  There is every reason to believe that 
always indicates an error for which the programmer should appreciate a 
diagnostic message.  So one could consider that particular usage of 
inline to be a direct request for the compiler to perform that check, as 
opposed to placing inline just on the definition, in which case it would 
have the simpler meaning.

> And that also means to me, that there is no way to _not_ inline code if
> it is given in the header file,
Using the Intel 10 compiler at a decent level of optimization, it is a 
constant source of frustration that there is no way to tell it to not 
inline things defined in header files.  The project I work on has some 
very large templates that must be in header files and shouldn't be 
inlined.  The Intel 10 compiler always uses its own judgment and its own 
judgment is usually wrong.

I don't use GCC much in similar situations, but I don't think GCC is 
that flawed on this issue.  I think there are practical ways to get it 
to not inline such functions.
> It can compile the function to objectcode and
> use that more than once within one object if there are multiple calls.
>   
The intermediate form between the compiler and the linker allows for the 
compiler to generate a non inline copy of a function in each object 
module in which it is needed and then have the linker detect the 
duplication, keep only one copy, and connect all calls to that one copy.

That is often the behavior you want for a large function that must be 
defined in a header file.

Unless I missed something major, there is no way in the C++ language for 
the programmer to tell the compiler to process a function that way.  The 
Intel 10 compiler will process functions that way when it thinks it 
should (based on very stupid rules) but it cannot be told to.  I'm 
pretty sure GCC can be told to using attributes that are an extension to 
the C++ language.