about extern inline and static inline

[Sean]

I am a little confused by the "extern inline and static inline" rules. I
understand that "extern inline" guarantees no function storage is
created (all are inlined). But the following test seems to contradict
what I expect---I found inc_i() is actually compiled as a linkable
function in the a.out

>g++ main.cpp call_inc.cpp
>nm a.out

......
0804875e W _Z5inc_iv

Can someone explain what's wrong with my understanding? Even better, I
would appreciate if you can show me the comprehensive rule of "static
inline" and "extern inline".

Thanks,
Sean

--------------------------------
//myheader.h
extern int i;
extern void call_inc_i();
extern inline void inc_i(){
i++;
}

-------------------------------
//main.cpp
#include <iostream>
#include "myheader.h"
using namespace std;
int i = 0;
int main(){
inc_i();
cout << "after inc_i()" << i << endl;
call_inc_i();
cout << "after call_inc_i()" << i << endl;
}

--------------------------------
//call_inc.cpp
#include "myheader.h"
void call_inc_i(){
inc_i();
}
--------------------------------------

 

[Jonathan Mcdougall]

I am a little confused by the "extern inline and static inline" rules. I
understand that "extern inline" guarantees no function storage is
created (all are inlined).

This is incorrect in C++ (and I suspect it is an extension of gcc).
Inlining never guarantees anything (expect that the compiler will *try*
to inline it).

But the following test seems to contradict
what I expect---I found inc_i() is actually compiled as a linkable
function in the a.out

This is a normal behavior. Not all functions may be inlined. Compilers
are usually better than we are at inlining functions.

Can someone explain what's wrong with my understanding? Even better, I
would appreciate if you can show me the comprehensive rule of "static
inline" and "extern inline".

inline
tells the compiler to try to inline that function (it may refuse for
various reasons)

extern
redundant for a function but for an object, transforms a definition
into a declaration

static
for a namespace-scope name (not in a class), makes it local to the
translation
unit (roughly the file in which it is defined). However, this is
deprecated in C++,
unnamed namespaces should be used instead.

static inline and static extern are both combinations of the two terms.

Note that this does not apply to extern "C", which is a different
beast.


Jonathan

 

[Sean]

This is incorrect in C++ (and I suspect it is an extension of gcc).
Inlining never guarantees anything (expect that the compiler will *try*
to inline it).




This is a normal behavior. Not all functions may be inlined. Compilers
are usually better than we are at inlining functions.




inline
tells the compiler to try to inline that function (it may refuse for
various reasons)

extern
redundant for a function but for an object, transforms a definition
into a declaration

static
for a namespace-scope name (not in a class), makes it local to the
translation
unit (roughly the file in which it is defined). However, this is
deprecated in C++,
unnamed namespaces should be used instead.

static inline and static extern are both combinations of the two terms.

but if extern inline means "extern + inline" (simple combination), there
exist two definition of incr_i() in my example--since myheader.h is
included in main.cpp and call_inc.cpp.
There must be some special meaning besides simple combination, I guess.

 

[Jonathan Mcdougall]

I have to change that last sentence. Only using static on objects in a
namespace scope is deprecated. Using static on functions is legal.

but if extern inline means "extern + inline" (simple combination), there
exist two definition of incr_i() in my example--since myheader.h is
included in main.cpp and call_inc.cpp.
There must be some special meaning besides simple combination, I guess.

No. As I said, extern for a function is redundant (a function always
has external linkage, unless it is static) so let's forget about it. If
a function is inline, its *definition* (body) is actually *required* in
each translation unit it used. Think: if the definition is not
available, how can it be inlined? Multiple definitions (in different
translation units) of an inline function is not only legal, but
required.

If the function is both static and inline, it may confuse the compiler,
which will probably decide not to inline the function. Because the
function is static, each translation unit will get its copy. If the
compiler honors the inline hint, each translation unit will have its
copy of the function inlined.


Jonathan

 

[Rolf Magnus]

I am a little confused by the "extern inline and static inline" rules. I
understand that "extern inline" guarantees no function storage is
created (all are inlined).

No, it doesn't guarantee that at all. On the contrary. If a function is
extern, it must be linkable, so a non-inlined version must usually exist.
Using 'inline' doesn't really guarantee inlining at all. The only effect of
it regarding the C++ standard is that you can violate the
one-definition-rule. To the compiler, it's just a mere hint that you would
like the function to be inlined. The compiler might choose to ignore it, or
it might choose to inline functions that are not declared 'inline'.

But the following test seems to contradict what I expect---I found inc_i()
is actually compiled as a linkable
function in the a.out
.....
0804875e W _Z5inc_iv

Can someone explain what's wrong with my understanding? Even better, I
would appreciate if you can show me the comprehensive rule of "static
inline" and "extern inline".

static means that the function can only be used in the translation unit
where it's defined. extern means it can be used in any translation unit of
the program. inline means that a function can be defined in multiple
translation units without an error.