exporting inline functions

[Bilgehan.Balban]

Hi,

My observation was that a function with `inline' qualifier has file
scope in C++ and it's symbol is not exported. Contrary to this, in C an
`inline' function symbol is exported, unless it also has `static' or
`extern' qualifiers.

How could I achieve the C behaviour in C++, in that an inline function
symbol is exported? I see that one way to do it is declaring the
function in a class definition in a header file so that all files
including it get the copy of the function. Is there no way to share in
the symbol level? I think it is useful because one may want to have a
library of functions that are used inline, whenever they're referenced.

Thanks,
Bahadir

 

[Alf P. Steinbach]

* (e-mail address removed):

My observation was that a function with `inline' qualifier has file
scope in C++ and it's symbol is not exported.

Presumably by "file scope" you mean internal linkage, and by "not
exported" you mean internal linkage.

No, it's not that way.

Contrary to this, in C an
`inline' function symbol is exported, unless it also has `static' or
`extern' qualifiers.

I think you got this one wrong too.

How could I achieve the C behaviour in C++, in that an inline function
symbol is exported? I see that one way to do it is declaring the
function in a class definition in a header file so that all files
including it get the copy of the function. Is there no way to share in
the symbol level? I think it is useful because one may want to have a
library of functions that are used inline, whenever they're referenced.

An external linkage "inline" function must be defined (identically) in
every translation it's used. The "inline" qualifier informs the
compiler and linker that all definitions are the same. Hence the linker
can choose any single one, and you don't get a multiple def error.

 

[Bilgehan.Balban]

* (e-mail address removed):

Presumably by "file scope" you mean internal linkage, and by "not
exported" you mean internal linkage.

Yes you're right on this, after posting I realised `file scope' isn't
what I was trying to say.

I think you got this one wrong too.

An external linkage "inline" function must be defined (identically) in
every translation it's used. The "inline" qualifier informs the
compiler and linker that all definitions are the same. Hence the linker
can choose any single one, and you don't get a multiple def error.

By external linkage inline I guess you mean a declaration like:
extern inline void function(void) { }

I have seen the same description (i.e. picking up any definition) as
yours in gcc documentation and it makes sense.

Getting back to my original argument however, using gcc and producing
an object file in C, I have observed that no symbol was exported
(internal linkage) for a function declared "extern inline". This makes
me think, does the compiler avoid multiple def errors by not exporting
the symbol in the object file produced? My expectation would be to have
multiple definitions of same symbol in many object files and the linker
would resolve it by picking only one of them, because they're marked as
external linkage, in the object file level. Incorrect?

If we get back to just "inline" declaration, C compilation did export
the symbol in the object file produced.* However in C++, merely
declaring a function `inline' only, I had no exported symbols from the
file. Do you think this is how it's supposed to be?

Many thanks,
Bahadir

*I am using something like gcc -c file.c to produce the object file.

 

[Alf P. Steinbach]

* (e-mail address removed):

Yes you're right on this, after posting I realised `file scope' isn't
what I was trying to say.



By external linkage inline I guess you mean a declaration like:
extern inline void function(void) { }

Just

inline void function() {}

means the same.

I have seen the same description (i.e. picking up any definition) as
yours in gcc documentation and it makes sense.

Getting back to my original argument however, using gcc and producing
an object file in C, I have observed that no symbol was exported
(internal linkage) for a function declared "extern inline".

The compiler doesn't need to place the symbol in the object code, it's
just allowed to do that.

Especially if this is a small function that's naturally machine-code
inlined everywhere, and you don't take its address, there's no separate
function around after compilation.

Then it would just be more work for the linker if the compiler emitted
the function symbol.

This makes
me think, does the compiler avoid multiple def errors by not exporting
the symbol in the object file produced?

It might, but I don't think so.

Anyway the standard does not go into how a compiler should achieve the
required effect.

It does not even acknowledge the existence of compilers... ;-)

My expectation would be to have
multiple definitions of same symbol in many object files and the linker
would resolve it by picking only one of them, because they're marked as
external linkage, in the object file level. Incorrect?

Try taking the address the of the function and passing it around. Then
the function has to exist, and the compiler needs to ensure that you
have the same address as will be obtained in any other translation unit.
Hence it "must" (with a reasonable way of doing things) emit the
function symbol in the object code.

If we get back to just "inline" declaration, C compilation did export
the symbol in the object file produced.* However in C++, merely
declaring a function `inline' only, I had no exported symbols from the
file. Do you think this is how it's supposed to be?

See above; when the compiler can get away with it, it's free to do so.