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.
