inline function

J

jg

Does C++ standard require an inline function be generated all the
time ?

For example,

#include <iostream>
using namespace std;

inline int foo()
{
return 10;
}

int main()
{
cout << "foo()=" << foo() << endl;
}

Should foo() be generated in the final executable all the time ?

JG
 
T

tony_in_da_uk

Does C++ standard require an inline function be generated all the
time ?

inline is just a hint or request of the compiler, and doesn't promise
anything...

Tony
 
N

Neelesh Bodas

Does C++ standard require an inline function be generated all the
time ?
The correct term is "inlined", not "generated".

Given that, the answer is that the standard doesnot require an inline
function to be inlined all the time.

-N
 
J

jg

The correct term is "inlined", not "generated".

Given that, the answer is that the standard doesnot require an inline
function to be inlined all the time.

-N

No. I mean "generated". Whether an inline function is inlined or not
is not my question. My question is whether a compiler will generate
the code for that inline function no matter whether the function
is inlined or not.

For my example, I tried g++. Without optimization, it does generate
foo(); with -O, it does not. With Sun Studio 11, it does not generate
foo() even without optimization.

JG



it does generate that
 
I

Ian Collins

jg said:
No. I mean "generated". Whether an inline function is inlined or not
is not my question. My question is whether a compiler will generate
the code for that inline function no matter whether the function
is inlined or not.
The answer has to be yes, if the function is used. Code will either be
generated inline where it is called, or elsewhere if the compiler
decides not to inline the function.

There is no requirement to generate a stand alone function.
 
N

nallayan77

The answer has to be yes, if the function is used. Code will either be
generated inline where it is called, or elsewhere if the compiler
decides not to inline the function.

There is no requirement to generate a stand alone function.

Hi Jg,
It is up to the compiler based on the size of the piece of
inline code constructed by the programmer.
If the compiler feels not to make the piece as inline(because of
larger size), it does not generate the inline code.

Thanks,
nalla
 
J

James Kanze

Does C++ standard require an inline function be generated all the
time ?
For example,
#include <iostream>
using namespace std;
inline int foo()
{
return 10;
}
int main()
{
cout << "foo()=" << foo() << endl;
}
Should foo() be generated in the final executable all the time ?

I'm not sure what you mean by "generated". The language defines
the semantics of a given C++ program (provided there is no
undefined behavior). Those semantics result in one or more
possible "observable behavior". Basically, the language
standard then says that a compiler can do whatever it wants, as
long as executing the resulting program results in one of the
observable behaviors.

On a Unix, machine, for example, for the above a compiler could
legally generate something like:
write( 1, "foo()=10\n", 9 ) ;
return 0 ;
Most compilers will probably generate something like:
cout << "foo()=" << 10 << endl ;
return 0 ;
for the above.

Some compilers might also generate an out of line copy of foo(),
perhaps to simplify debugging (e.g. if you've asked for
debugging information). What the compiler generates, however,
doesn't matter as long as executing the code results in an
observable behavior which corresponds to the specified
semantics.
 
J

Juha Nieminen

Hi Jg,
It is up to the compiler based on the size of the piece of
inline code constructed by the programmer.
If the compiler feels not to make the piece as inline(because of
larger size), it does not generate the inline code.

I think you are all being a bit obtuse here. He is clearly asking
whether a (non-inlined) subroutine for the function will be generated
in the final binary regardless of whether the compiler inlined its
contents in the only place where it was called or not.

Or if we word it in another way: Even if the compiler inlined the
contents of the function at the calling location, will the contents
of the function also exist as a non-inlined function in the final
binary (even if this non-inlined version is never called anywhere)?

I don't know what the standard says, but IIRC at least gcc has a
command-line option to force it to create non-inlined instances of
inline functions regardless of whether they are necessary or not.
 
A

Andre Kostur

Does C++ standard require an inline function be generated all the
time ?

For example,

#include <iostream>
using namespace std;

inline int foo()
{
return 10;
}

int main()
{
cout << "foo()=" << foo() << endl;
}

Should foo() be generated in the final executable all the time ?

Not necessarily. If the function is declared as inline, the function body
may never exist in the final executable. There are certain actions which
will guarantee that it does exist (like taking it's address), and you can't
guarantee that the function body will _not_ be in the executable.
 
J

jg

Thanks for all answers.

To summarize, C++ standard does not require that the out-of-line code
of an inline function be generated all the time. It looks like C++
standard does not have explicit wording about this (at least I don't
find one); and I take it as whether to generate out-of-line code is a
up to an implementation.

The reason I was asking this is that in C Standard (C99), a compiler
must not generate the out-of-line code of an inline function, even
there
are calls to that inline function and those calls are not inlined.
 
J

James Kanze

To summarize, C++ standard does not require that the out-of-line code
of an inline function be generated all the time. It looks like C++
standard does not have explicit wording about this (at least I don't
find one); and I take it as whether to generate out-of-line code is a
up to an implementation.
The reason I was asking this is that in C Standard (C99), a compiler
must not generate the out-of-line code of an inline function, even
there
are calls to that inline function and those calls are not inlined.

That's wrong. Neither C nor C++ constrain the implementation in
any way in this regard. In both cases, if a function is
declared inline, its definition may appear in multiple
translation units, the compiler is not required to inline it,
but may just generate a local copy and call it, and the compiler
is free to generate a local copy even if it does inline the
function. The only difference is that in C++, the compiler is
more or less required to "merge" all of the local copies, C
restricts what you can inline so that a conformant program
cannot tell whether the local copies have been merged or not.
 
J

jg

To clarify, I meant that C standard requires that the out-of-line copy
of an INLINE FUNCTION must not be generated in that translation unit.
And its linkage is external. A call to that inline function, if not
inlined, must be satisfied by an external definition of that inline
function in another translation unit.
That's wrong. Neither C nor C++ constrain the implementation in

Unfortunately, that is not wrong. Whether this requirement in C
is good or not is another issue. If you have C standard (C99),
you can check its definition of inline function (C defines inline
function in its own way).

JG
 
J

James Kanze

To clarify, I meant that C standard requires that the
out-of-line copy of an INLINE FUNCTION must not be generated
in that translation unit.

Which is simply wrong. Neither the C nor the C++ standard ever
make any requirements with regards to what is or is not
generated. The requirements only concern the behavior of the
compiled code.
And its linkage is external. A call to that inline function, if not
inlined, must be satisfied by an external definition of that inline
function in another translation unit.

Again, that's not what the C standard says. The C standard says
that there must be a non-inline definition of the function
somewhere, and that it is unspecified whether you get the
non-inline definition (possibly in another translation unit) or
the inline definition (immediately visible). Except for
requiring the non-inline definition, and making the behavior
unspecified (rather than undefined), this is not so radically
different from the C++ standard. Basically: if a function is
inline, it can (and doubtlessly will) be defined in many
different places in the program. In C++, if the definitions are
not identical, the behavior is undefined. In C, it is
unspecified which definition you actually get.
Unfortunately, that is not wrong. Whether this requirement in C
is good or not is another issue. If you have C standard (C99),
you can check its definition of inline function (C defines inline
function in its own way).

I did that immediately before posting, thank you. The C
standard, like the C++ standard, never says the slightest thing
about what the compiler generates. All it specifies is the
behavior of the program. In particular, we find: "The function
specifier may appear more than once; the behavior is the same as
if it appeared only once. Making a function an inline function
suggests that calls to the function be as fast as possible. The
extent to which such suggestions are effective is
implementation-defined."

Clearly, whether the compiler lays out an out of line copy or
not is up to the compiler. (And I rather suspect that the
"implementation-defined", rather than "unspecified", is a
defect. I don't really expect a compiler to document its
choices here, as they doubtlessly depend on optimization and
debug options.)
 
J

jg

Which is simply wrong. Neither the C nor the C++ standard ever
make any requirements with regards to what is or is not
generated. The requirements only concern the behavior of the
compiled code.


Again, that's not what the C standard says. The C standard says
that there must be a non-inlinedefinition of thefunction
somewhere, and that it is unspecified whether you get the
non-inlinedefinition (possibly in another translation unit) or
theinlinedefinition (immediately visible). Except for
requiring the non-inlinedefinition, and making the behavior
unspecified (rather than undefined), this is not so radically
different from the C++ standard. Basically: if afunctionisinline, it can (and doubtlessly will) be defined in many
different places in the program. In C++, if the definitions are
not identical, the behavior is undefined. In C, it is
unspecified which definition you actually get.


I did that immediately before posting, thank you. The C
standard, like the C++ standard, never says the slightest thing
about what the compiler generates. All it specifies is the
behavior of the program. In particular, we find: "Thefunction
specifier may appear more than once; the behavior is the same as
if it appeared only once. Making afunctionaninlinefunction
suggests that calls to thefunctionbe as fast as possible. The
extent to which such suggestions are effective is
implementation-defined."

Here is the text from C99, section 6.7.4 (6)

<quote>
Any function with internal linkage can be an inline function. For a
function with external
linkage, the following restrictions apply: If a function is declared
with an inline function
specifier, then it shall also be defined in the same translation unit.
If all of the
file scope declarations for a function in a translation unit include
the inline function
specifier without extern, then the definition in that translation unit
is an inline
definition. An inline definition does not provide an external
definition for the function,
and does not forbid an external definition in another translation
unit. An inline definition
provides an alternative to an external definition, which a translator
may use to implement
any call to the function in the same translation unit. It is
unspecified whether a call to the
function uses the inline definition or the external definition.120)
From the above, you can see that a translator cannot provide an
external definition of
the function (that is, no out-of-line code is generated in that
tranlation unit).

JG
 
J

James Kanze

Here is the text from C99, section 6.7.4 (6)
<quote>
Any function with internal linkage can be an inline function.
For a function with external linkage, the following
restrictions apply: If a function is declared with an inline
function specifier, then it shall also be defined in the same
translation unit. If all of the file scope declarations for a
function in a translation unit include the inline function
specifier without extern, then the definition in that
translation unit is an inline definition. An inline
definition does not provide an external definition for the
function, and does not forbid an external definition in
another translation unit. An inline definition provides an
alternative to an external definition, which a translator may
use to implement any call to the function in the same
translation unit. It is unspecified whether a call to the
function uses the inline definition or the external
definition.
<end of quote>
From the above, you can see that a translator cannot provide
an external definition of the function (that is, no
out-of-line code is generated in that tranlation unit).
From the above, I can't see the slightest restriction concerning
what a compiler generates. Read it again. It is explicitly
unspecified whether the implementation uses the inline
definition or the external definition. There's absolutely
nothing there about what the compiler may or may not generate.

Given the way linkers have historically worked, the first part
is sort of true (for a definition of "external" that the
standarfd doesn't use). The compiler can't do anything which
would cause the linker to declare multiple definitions. But
that's totally irrelevant with regards to what you put in
parentheses. Even with older linkers, all the compiler has to
do is generate the out of line copy as if it were declared
static (which is what most early C++ compilers did).

Again: neither the C nor the C++ ever say anything about what an
implementation may or may not generate. It's a fundamental
principal underlying both standards. The compiler can do
absolutely anything, as long as the observable behavior of the
program is correct.
 
J

jg

what a compiler generates. Read it again. It is explicitly
unspecified whether the implementation uses theinline
definition or the external definition.

Definitely, but this is never my question.
There's absolutely
nothing there about what the compiler may or may not generate.

This is what we are arguing now.
Given the way linkers have historically worked, the first part
is sort of true (for a definition of "external" that the
standarfd doesn't use). The compiler can't do anything which
would cause the linker to declare multiple definitions. But
that's totally irrelevant with regards to what you put in
parentheses.

No, it is relevant. We are discussing an inline function with
external linkage (ie external function). If the out-of-line
code is generated in that translation unit and it cannot provide
the external definition to that function, what would it be ?
What is its name (or linker symbol) ?

Don't you agree that "does not provide the external definition"
means the out-of-line code will not be generated !

Even with older linkers, all the compiler has to
do is generate the out of line copy as if it were declared
static (which is what most early C++ compilers did).

I know. But it is not C99 conforming. Doing this will
causes two function pointers to the same external function
to point to different things!
Again: neither the C nor the C++ ever say anything about what an
implementation may or may not generate. It's a fundamental
principal underlying both standards. The compiler can do
absolutely anything, as long as the observable behavior of the
program is correct.

It is a general principle. But remember that what is the
observable behavior is up to many different explanations, sometimes
subjective. To one person who works on an linker or a binary tool,
an additional definition in an object file is observable. To another
who is debugging his code, he suddenly cannot his function in
the final executable, which is observerable to him.

I think we have to restrict our discussion within the context of
C99 standard and the state-of-art implementation.

JG
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,733
Messages
2,569,440
Members
44,831
Latest member
HealthSmartketoReviews

Latest Threads

Top