This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Understanging the use of inline funtions


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.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]