inline keyword and linkage

[Grumble]

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() { } ?

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 */

--
Regards, Grumble

[Ioannis Vranos]

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

[Mike Wahler]

"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

[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

[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

[Ioannis Vranos]

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?
"Unfortunat ely, 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

[Andrey Tarasevich]

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
"communicat ion" 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

[Andrey Tarasevich]

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

[Mike Wahler]

"Ioannis Vranos" <iv*@remove.thi s.grad.com> wrote in message
news:1108405964 .548619@athnrd0 2...

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.
"Unfortunat ely, 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

[Mike Wahler]

"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