is there an interest in a project of commenting fruit2.1?

[mathmoi]

Putting inline implementations into .h files instead, not .cpp files, will work.

I suspect that GCC would complain that the same function in multiple source files in that case (I haven't tried, though). Perhaps defining the functions as 'static inline' and placing them in .h files would work.

Tord

Hi Tord,

In fact inline function must be implemented in the .h file. The compiler will not complain. Since the function is inlined it's definition must be know while compiling a call to it, this is why you must put the definition of the function in the header file. Otherwise inline is ignored

Strangely, most other compilers get it right (MS, Intel, Compaq, etc.)

There is no reason that the compiler cannot rearrange things to its liking.

The GCC design is just lazy.

It is not supposed to cause problems if the implementations of an inline function is not written in the header files. It will just not be inlined.

[Dann Corbit]

Right. The result will be correct, but slower than it might be otherwise.

And you can work around it, but the work around is grotesque.

[Sven Schüle]

Hi Dann,

is it possible that there is still some confusion about the truth of inline functions at your side?

The compiler (not only GCC, true for all C/C++ compilers) _must_ see the body of a function in order to be able to inline it. So he _can't_ inline a function if its body is defined in another cpp file but not in a header file #included in the current compile unit.

He _may_ also inline a function which has no "inline" keyword (but this should not occur within a header file, it might cause duplicate symbols for the linker if the function is not inlined). Perhaps this is a point where compilers are different, although I think that GCC is already quite good in this area.

Btw, nobody should expect too much from this "inlining" topic, it's just an optimization, and you can live a long time without it.

Sven

[Sven Schüle]

Hi "mathmoi",

this is why you must put the definition of the function in the header file. Otherwise inline is ignored

just a short note on this: a function which is only used within one compile unit (one cpp file) can be inlined even if its body appears in the cpp file, provided the body appears before the function call(s). The compiler makes no difference between cpp and h files, he just reads an input stream presented to him by the preprocessor (I suspect you know this )

The advice to put inline implementations into header files is valid for functions used in more than cpp file (same principle as for function protoypes).

Sven

[Dann Corbit]

Hi Dann,

is it possible that there is still some confusion about the truth of inline functions at your side?

The compiler (not only GCC, true for all C/C++ compilers) _must_ see the body of a function in order to be able to inline it. So he _can't_ inline a function if its body is defined in another cpp file but not in a header file #included in the current compile unit.

He _may_ also inline a function which has no "inline" keyword (but this should not occur within a header file, it might cause duplicate symbols for the linker if the function is not inlined). Perhaps this is a point where compilers are different, although I think that GCC is already quite good in this area.

Btw, nobody should expect too much from this "inlining" topic, it's just an optimization, and you can live a long time without it.

Sven

It is to a large degree, a tempest in a teapot. The overhead of a function call is small anyway.

If a compiler wants to, it can look at every clump of assembly it generates for every function in a project and inline any of those it chooses.

If it wants to "see" a function, all it has to do is to make two passes.