inline keyword and linkage

Grumble wrote:

Hello everyone,

As far as I understand, the 'inline' keyword is a hint for the compiler
to consider the function in question as a candidate for inlining, yes?

What happens when a function with extern linkage is inlined? Should the
compiler still export the function?

Or is an inlined function implicitly static?

Is extern inline foo() { } a legal function defintion?

Is inline foo(...) { } different from inline foo() { } ?

As it is mentioned in TC++PL 3 on page 199:
"An inline function (7.1.1, 10.2.9) must be defined – by identical
definitions (9.2.3) – in every translation unit in which it is used.

Consequently, the following example isn't just bad taste; it is illegal:

// file1.c:
inline int f(int i) { return i; }
// file2.c:
inline int f(int i) { return i+1; }
Unfortunately, this error is hard for an implementation to catch, and
the following – otherwise perfectly logical – combination of external
linkage and inlining is banned to make life simpler for compiler writers:
// file1.c:
extern inline int g(int i);

int h(int i) { return g(i); } // error: g() undefined in this
//translation unit

// file2.c:
extern inline int g(int i) { return i+1; }"

--
Ioannis Vranos

http://www23.brinkster.com/noicys

Jul 23 '05 #2

"Grumble" <de*****@kma.eu.org> wrote in message
news:cu**********@news-rocq.inria.fr...

Hello everyone,

As far as I understand, the 'inline' keyword is a hint for the compiler
to consider the function in question as a candidate for inlining, yes?
Yes.

What happens when a function with extern linkage is inlined?
Nothing special.
Should the
compiler still export the function?
Unless it's explicitly specified as static, it has
external linkage, whether it's declared inline or not.
But there is a further requirement about an inline
function *definition*, cited below.
Or is an inlined function implicitly static?
No.

Is extern inline foo() { } a legal function defintion?
Yes.

Is inline foo(...) { } different from inline foo() { } ?
Yes, the signatures are different.

I was somewhat confused after reading
http://cpptips.hyperformix.com/cpptips/extern_inline3

$ cat foo.cxx
extern inline int foo(int n)
{
int sum = 0;
for (int i = 0; i < n; ++i) sum += i;
return sum;
}

$ g++-3.4.3 -std=c++98 -Wall -Wextra -pedantic -c foo.cxx

$ nm foo.o
/* NO SYMBOLS EXPORTED */

================================================== ==============
ISO/IEC 14882:1998(E)

.....

3.2 One definition rule

3 Every program shall contain exactly one definition of every
non*inline function or object that is used in that program;
no diagnostic required. The definition can appear explicitly
in the program, it can be found in the standard or a user-
*defined library, or (when appropriate) it is implicitly defined
(see 12.1, 12.4 and 12.8). An inline function shall be defined
in every translation unit in which it is used.

.....

3.5 Program and linkage

3 A name having namespace scope (3.3.5) has internal linkage
if it is the name of
-- an object, reference, function or function template that
is explicitly declared static or,
-- an object or reference that is explicitly declared const
and neither explicitly declared extern nor previously
declared to have external linkage; or
-- a data member of an anonymous union.

4 A name having namespace scope has external linkage if it is
the name of
-- an object or reference, unless it has internal linkage; or
-- a function, unless it has internal linkage; or
-- a named class (clause 9), or an unnamed class defined in
a typedef declaration in which the class has the
typedef name for linkage purposes (7.1.3); or
-- a named enumeration (7.2), or an unnamed enumeration defined
in a typedef declaration in which the
enumeration has the typedef name for linkage purposes
(7.1.3); or
-- an enumerator belonging to an enumeration with external
linkage; or
-- a template, unless it is a function template that has internal
linkage (clause 14); or
-- a namespace (7.3), unless it is declared within an unnamed
namespace.

.....

7.1.2 Function specifiers

4 An inline function shall be defined in every translation
unit in which it is used and shall have exactly the same
definition in every case (3.2). [Note: a call to the inline
function may be encountered before its defi*nition appears
in the translation unit. ] If a function with external
linkage is declared inline in one transla*tion unit, it
shall be declared inline in all translation units in which
it appears; no diagnostic is required. An inline function
with external linkage shall have the same address in all
translation units. A static local variable in an extern
inline function always refers to the same object. A string
literal in an extern inline function is the same object in
different translation units.
================================================== ==============

-Mike

Jul 23 '05 #3

Ivan Vecerina

"Grumble" <de*****@kma.eu.org> wrote in message
news:cu**********@news-rocq.inria.fr...

Hello everyone, Hi, As far as I understand, the 'inline' keyword is a hint for the compiler
to consider the function in question as a candidate for inlining, yes? Yes.
What happens when a function with extern linkage is inlined? A function declared as "extern inline" is only guaranteed to
have the same address in all translation units that take that
address.
Should the compiler still export the function? Not necessarily.
Or is an inlined function implicitly static? No, as far as I understand: the function may still have
linkage (and its name be exported).
Is extern inline foo() { } a legal function defintion? Yes.
Is inline foo(...) { } different from inline foo() { } ? Yes, inline functions can be overloaded.
I was somewhat confused after reading
http://cpptips.hyperformix.com/cpptips/extern_inline3

The situation is a bit complex, because implementors
have some freedom in how they implement inline functions.
FYI, here's the exact wording of the standard (7.1.2/2-4):

A function declaration (8.3.5, 9.3, 11.4) with an inline specifier declares
an inline function. The inline

specifier indicates to the implementation that inline substitution of the
function body at the point of call is

to be preferred to the usual function call mechanism. An implementation is
not required to perform this

inline substitution at the point of call; however, even if this inline
substitution is omitted, the other rules for

inline functions defined by 7.1.2 shall still be respected.

A function defined within a class definition is an inline function. The
inline specifier shall not appear

on a block scope function declaration.79)

An inline function shall be defined in every translation unit in which it is
used and shall have exactly the

same definition in every case (3.2). [Note: a call to the inline function
may be encountered before its definition

appears in the translation unit. ] If a function with external linkage is
declared inline in one translation

unit, it shall be declared inline in all translation units in which it
appears; no diagnostic is required. An

inline function with external linkage shall have the same address in all
translation units. A static

local variable in an extern inline function always refers to the same
object. A string literal in an

extern inline function is the same object in different translation units.

hth
Ivan
--
http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form

Jul 23 '05 #4

Grumble

Grumble wrote:

Is inline foo(...) { } different from inline foo() { } ?

I meant:

Is "inline foo(...) { }" different from "extern inline foo(...) { }" ?

(Two mistakes in a single line, Doh!)

--
Regards, Grumble

Jul 23 '05 #5

Ivan Vecerina wrote:

The situation is a bit complex, because implementors
have some freedom in how they implement inline functions.
FYI, here's the exact wording of the standard (7.1.2/2-4):

A function declaration (8.3.5, 9.3, 11.4) with an inline specifier declares
an inline function. The inline

specifier indicates to the implementation that inline substitution of the
function body at the point of call is

to be preferred to the usual function call mechanism. An implementation is
not required to perform this

inline substitution at the point of call; however, even if this inline
substitution is omitted, the other rules for

inline functions defined by 7.1.2 shall still be respected.

A function defined within a class definition is an inline function. The
inline specifier shall not appear

on a block scope function declaration.79)

An inline function shall be defined in every translation unit in which it is
used and shall have exactly the

same definition in every case (3.2). [Note: a call to the inline function
may be encountered before its definition

appears in the translation unit. ] If a function with external linkage is
declared inline in one translation

unit, it shall be declared inline in all translation units in which it
appears; no diagnostic is required. An

inline function with external linkage shall have the same address in all
translation units. A static

local variable in an extern inline function always refers to the same
object. A string literal in an

extern inline function is the same object in different translation units.

So the following from TC++PL does not apply, or BS means something else
with it?
"Unfortunately, this error is hard for an implementation to catch, and
the following – otherwise perfectly logical – combination of external
linkage and inlining is banned to make life simpler for compiler writers:
// file1.c:
extern inline int g(int i);

int h(int i) { return g(i); } // error: g() undefined in this
//translation unit

// file2.c:
extern inline int g(int i) { return i+1; }"

extern inline is not banned in general, or the specific use (which is?)
is only banned?

--
Ioannis Vranos

http://www23.brinkster.com/noicys

Jul 23 '05 #6

Grumble wrote:

...
As far as I understand, the 'inline' keyword is a hint for the compiler
to consider the function in question as a candidate for inlining, yes?
Yes.
What happens when a function with extern linkage is inlined? Should the
compiler still export the function?
Maybe. Remember, that there are contexts where inline functions cannot
be actually inlined. For example, if you take the address of that
function, store it in a pointer and then, later, cal it through that
pointer. In general case, in order to serve this call the compiler has
no other choice but to generate a "regular" (non-inlined ) body for this
function. Now, if this function has external linkage, the compiler has
to make sure that all such pointers obtained in all translation units
have the same value (even though every translation units is required to
include it's own copy of the definition of the inline function). In
order to achieve that the compiler has to establish some form of
"communication" between translation units. Traditionally, this is done
by exporting the inline function from all modules where it has a
"regular" body. Later, the linker will choose one and only one of the
exported bodies for each function and discard all others.

Note, that the above exporting is done for a purely internal purpose. It
does not mean that the user is allowed to "link" to that exported
function from other translation units by providing a mere declaration of
the function there

--- file1.c ---

inline void foo() {}

--- file2.c ---

void foo();

int main() {
foo();
// Might compile and "work" in practice, but is not supported by
// the language. The behavior is undefined
}

----------------

The compiler is free prevent the above code from compiling (for example,
by using a dedicated name mangling convention for exported inline
function bodies, different from the convention used with regular functions).
Or is an inlined function implicitly static?
No. Inline functions are have external linkage by default, just like
regular functions.
Is extern inline foo() { } a legal function defintion?
Yes. But see above.
Is inline foo(...) { } different from inline foo() { } ?
Hm... Yes. The argument declarations are different. But in this case the
difference has nothing to do with inlining.
I was somewhat confused after reading
http://cpptips.hyperformix.com/cpptips/extern_inline3

$ cat foo.cxx
extern inline int foo(int n)
This 'extern' is superfluous.
{
int sum = 0;
for (int i = 0; i < n; ++i) sum += i;
return sum;
}

$ g++-3.4.3 -std=c++98 -Wall -Wextra -pedantic -c foo.cxx

$ nm foo.o
/* NO SYMBOLS EXPORTED */

Not surprising. In this translation unit you are not given the compiler
any reason to generate a regular body for the inline function. Since
there's no body, there's nothing to export.

Try taking the address of the function and using it in some non-trivial
fashion. See what will happen. Something like this

inline int foo(int n)
{
int sum = 0;
for (int i = 0; i < n; ++i) sum += i;
return sum;
}

int bar(int i, int (*fn)(int))
{
return (*fn)(i);
}

int baz()
{
return bar(100, &foo);
}

--
Best regards,
Andrey Tarasevich

Jul 23 '05 #7

Andrey Tarasevich wrote:

Sorry for multiple typos in my previous post

be actually inlined. For example, if you take the address of that
function, store it in a pointer and then, later, cal it through that ^^^^
call ...
have the same value (even though every translation units is required to ^^^^^
unit ...
The compiler is free prevent the above code from compiling (for example, ^^
to ...
Or is an inlined function implicitly static?
No. Inline functions are have external linkage by default, just like

^^^^^^^^^^^^^^^^^^
functions have ...
Not surprising. In this translation unit you are not given the compiler

^^^
have

--
Best regards,
Andrey Tarasevich

Jul 23 '05 #8

"Ioannis Vranos" <iv*@remove.this.grad.com> wrote in message
news:1108405964.548619@athnrd02...

Ivan Vecerina wrote:
The situation is a bit complex, because implementors
have some freedom in how they implement inline functions.
FYI, here's the exact wording of the standard (7.1.2/2-4):

A function declaration (8.3.5, 9.3, 11.4) with an inline specifier declares an inline function. The inline

specifier indicates to the implementation that inline substitution of the function body at the point of call is

to be preferred to the usual function call mechanism. An implementation is not required to perform this

inline substitution at the point of call; however, even if this inline
substitution is omitted, the other rules for

inline functions defined by 7.1.2 shall still be respected.

A function defined within a class definition is an inline function. The
inline specifier shall not appear

on a block scope function declaration.79)

An inline function shall be defined in every translation unit in which it is used and shall have exactly the

same definition in every case (3.2). [Note: a call to the inline function may be encountered before its definition

appears in the translation unit. ] If a function with external linkage is declared inline in one translation

unit, it shall be declared inline in all translation units in which it
appears; no diagnostic is required. An

inline function with external linkage shall have the same address in all
translation units. A static

local variable in an extern inline function always refers to the same
object. A string literal in an

extern inline function is the same object in different translation
units.
So the following from TC++PL does not apply, or BS means something else
with it?
Yes it does apply.
"Unfortunately, this error is hard for an implementation to catch, and
the following – otherwise perfectly logical – combination of external
linkage and inlining is banned to make life simpler for compiler writers:
// file1.c:
extern inline int g(int i);

int h(int i) { return g(i); } // error: g() undefined in this
//translation unit
The rules banning this are 3.2/3 and 7.1.2/4, which I cited
in my post elsethread.

// file2.c:
extern inline int g(int i) { return i+1; }"

extern inline is not banned in general,
No.
or the specific use (which is?)
is only banned?

What is banned is the use of an extern declaration in
place of a definition in the translation unit from where it
is called.
IMO the simplest way to deal with this is if you want to define
a nonmember function as inline, define it in a header, and
include the header in translation units which call it.

-Mike

Jul 23 '05 #9

"Grumble" <de*****@kma.eu.org> wrote in message
news:cu**********@news-rocq.inria.fr...

Grumble wrote:
Is inline foo(...) { } different from inline foo() { } ?

I meant:

Is "inline foo(...) { }" different from "extern inline foo(...) { }" ?

(Two mistakes in a single line, Doh!)

No, they're not different if declared at namespace scope,
because in that case 'extern' is implied; the specifier
is redundant.

-Mike

Jul 23 '05 #10

Mike Wahler wrote:

What is banned is the use of an extern declaration in
place of a definition in the translation unit from where it
is called.

Now I get it. Thanks for the info. There should be only inline
definitions with the keyword extern.
However is this also banned?
// file1.cpp:
extern inline int g(int i) { return i+1; }

int h(int i) { return g(i); } // error: g() undefined in this
//translation unit
// file2.cpp:

// No extern keyword here
inline int g(int i) { return i+1; }"

--
Ioannis Vranos

http://www23.brinkster.com/noicys

Jul 23 '05 #11

"Ioannis Vranos" <iv*@remove.this.grad.com> wrote in message
news:1108413100.623177@athnrd02...

Mike Wahler wrote:
What is banned is the use of an extern declaration in
place of a definition in the translation unit from where it
is called.

Now I get it. Thanks for the info. There should be only inline
definitions with the keyword extern.
However is this also banned?

No.
// file1.cpp:
extern inline int g(int i) { return i+1; }

int h(int i) { return g(i); } // error: g() undefined in this
//translation unit
The 'error' comment is incorrect. Above, 'g()' *is* defined
in this TU.

// file2.cpp:

// No extern keyword here
Doesn't matter, 'extern' is the default linkage for
a namespace scope function name.
inline int g(int i) { return i+1; }"

This has the same effect as if you'd used
the 'extern' keyword.

The rule you need be concerned with here, is that
the definition of 'g()' is the same in all TU's
which call it.

The appearance (or not) of the 'extern' keyword
doesn't change the definition. (But if you overload
'g()' by changing the parameter list, you'd need
to provide those same overloads in other TU's where
you invoke them).

Does that help?

-Mike

Jul 23 '05 #12

Ioannis Vranos wrote:

...
However is this also banned?
// file1.cpp:
extern inline int g(int i) { return i+1; }

int h(int i) { return g(i); } // error: g() undefined in this
//translation unit
// file2.cpp:

// No extern keyword here
inline int g(int i) { return i+1; }"
...

Yes, from the strictly formal and pedantic point of view, this is also
banned. All definitions of inline function 'g' are required to consist
from exactly the same sequences of tokens. In the above case this
requirement is not met.

--
Best regards,
Andrey Tarasevich

Jul 23 '05 #13

"Andrey Tarasevich" <an**************@hotmail.com> wrote in message
news:11*************@news.supernews.com...

Ioannis Vranos wrote:
...
However is this also banned?
// file1.cpp:
extern inline int g(int i) { return i+1; }

int h(int i) { return g(i); } // error: g() undefined in this
//translation unit
// file2.cpp:

// No extern keyword here
inline int g(int i) { return i+1; }"
...
Yes, from the strictly formal and pedantic point of view, this is also
banned. All definitions of inline function 'g' are required to consist
from exactly the same sequences of tokens.

Really? Where does 14998 specify this in terms of tokens?
In the above case this
requirement is not met.

-Mike

Jul 23 '05 #14

Mike Wahler wrote:

> ...
> // file1.cpp:
> extern inline int g(int i) { return i+1; }
>
> int h(int i) { return g(i); } // error: g() undefined in this
> //translation unit
>
>
> // file2.cpp:
>
> // No extern keyword here
> inline int g(int i) { return i+1; }"
> ...

Yes, from the strictly formal and pedantic point of view, this is also
banned. All definitions of inline function 'g' are required to consist
from exactly the same sequences of tokens.

Really? Where does 14998 specify this in terms of tokens?
...

I have to admit that I was looking at 3.2/5 in 14882. I just checked the
"unofficial list of revisions". It makes some changes to 3.2/5 but it
still says that for "inline function with external linkage" "each
definition [...] shall consist of the same sequence of tokens". Was this
requirement removed from the final 14998?

--
Best regards,
Andrey Tarasevich

Jul 23 '05 #15

"Andrey Tarasevich" <an**************@hotmail.com> wrote in message
news:11*************@news.supernews.com...

Mike Wahler wrote:
Yes, from the strictly formal and pedantic point of view, this is also
banned. All definitions of inline function 'g' are required to consist
from exactly the same sequences of tokens.

Really? Where does 14998 specify this in terms of tokens?
...

I have to admit that I was looking at 3.2/5 in 14882.

And I have to admit I made a typo above. :-) I meant to write
14882. :-)
I just checked the
"unofficial list of revisions". It makes some changes to 3.2/5 but it
still says that for "inline function with external linkage" "each
definition [...] shall consist of the same sequence of tokens".
OK I see it now, I missed that before. Thanks.
Was this
requirement removed from the final 14998?

AFAIK the current revision is 14998:2003. I have 14882:1998,
but I doubt the 2003 version changed the above. I also would
not be surprised if some implementations don't strictly enforce
this rule as regards 'extern' keyword, but I'm certainly happy
that you brought this to my attention. :-)

Thanks for the correction.

-Mike

Jul 23 '05 #16

E. Robert Tisdale

Grumble wrote:

As far as I understand,
the 'inline' keyword is a hint for the compiler
to consider the function in question
as a candidate for inlining, yes?

What happens when a function with extern linkage is inlined?
Should the compiler still export the function? cat foo.cc inline int foo(int n) {
int sum = 0;
for (int i = 0; i < n; ++i)
sum += i;
return sum;
}
g++ -Wall -ansi -pedantic -c foo.cc
nm foo.o
cat foo.cc extern inline int foo(int n) {
int sum = 0;
for (int i = 0; i < n; ++i)
sum += i;
return sum;
}
g++ -Wall -ansi -pedantic -c foo.cc
nm foo.o
cat foo.cc static inline int foo(int n) {
int sum = 0;
for (int i = 0; i < n; ++i)
sum += i;
return sum;
}
g++ -Wall -ansi -pedantic -c foo.cc
nm foo.o
cat foo.c inline int foo(int n) {
int sum = 0;
for (int i = 0; i < n; ++i)
sum += i;
return sum;
}
gcc -Wall -std=c99 -pedantic -c foo.c
nm foo.o 00000000 T foo cat foo.c extern inline int foo(int n) {
int sum = 0;
for (int i = 0; i < n; ++i)
sum += i;
return sum;
}
gcc -Wall -std=c99 -pedantic -c foo.c
nm foo.o
cat foo.c static inline int foo(int n) {
int sum = 0;
for (int i = 0; i < n; ++i)
sum += i;
return sum;
}
gcc -Wall -std=c99 -pedantic -c foo.c
nm foo.o

ANSI/ISO C99 inline functions have external linkage
unless they are defined static (or extern).

Jul 23 '05 #17

Mike Wahler wrote:

AFAIK the current revision is 14998:2003. I have 14882:1998,
but I doubt the 2003 version changed the above. I also would
not be surprised if some implementations don't strictly enforce
this rule as regards 'extern' keyword, but I'm certainly happy
that you brought this to my attention. :-)

Thanks for the correction.

2003:

"ï»¿There can be more than one definition of a class type (clause 9),
enumeration type (7.2), inline function with external linkage (7.1.2),
class template (clause 14), non-static function template (14.5.5),
static data member of a class template (14.5.1.3), member function of a
class template (14.5.1.1), or template specialization for which some
template parameters are not specified (14.7, 14.5.4) in a program
provided that each definition appears in a different translation unit,
and provided the definitions satisfy the following require-
ments. Given such an entity named D defined in more than one translation
unit, then

â€” each definition of D shall consist of the same sequence of tokens; and"
Well, a question first, spaces aren't also tokens?

Also what about
extern inline void somefunc() {}

inline extern void somefunc() {}

not to mention
inline void somefunc() {}

inline void somefunc(void) {}

Since extern is implied anyway and the explicit use of the keyword is
redundant, that is both
extern inline void somefunc() {}

inline void somefunc() {}

have the same meaning. But still they have different tokens. So strictly
speaking they are violating the one definition rule!

--
Ioannis Vranos

http://www23.brinkster.com/noicys

Jul 23 '05 #18

E. Robert Tisdale wrote:

ANSI/ISO C99 inline functions have external linkage
unless they are defined static (or extern).

Have you mistaken the newsgroups?

--
Ioannis Vranos

http://www23.brinkster.com/noicys

Jul 23 '05 #19