inline function

[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

[tony_in_da_uk]

On Jul 31, 8:51 am, jg <[e-mail]:

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

[Neelesh Bodas]

On Jul 31, 4:51 am, jg <[e-mail]:

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

[jg]

On Jul 30, 8:47 pm, Neelesh Bodas <[e-mail]:

On Jul 31, 4:51 am, jg <[e-mail]: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

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

[Ian Collins]

jg wrote:

On Jul 30, 8:47 pm, Neelesh Bodas <[e-mail]:

>On Jul 31, 4:51 am, jg <[e-mail]: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

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.

--
Ian Collins.

[nallayan77]

On Jul 31, 10:12 am, Ian Collins <[e-mail]:

jg wrote:

On Jul 30, 8:47 pm, Neelesh Bodas <[e-mail]:

On Jul 31, 4:51 am, jg <[e-mail]: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

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.

--
Ian Collins.

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

[James Kanze]

On Jul 31, 1:51 am, jg <[e-mail]:

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.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Juha Nieminen]

na********@gmail.com wrote:

On Jul 31, 10:12 am, Ian Collins <[e-mail]:

>jg wrote:

>>On Jul 30, 8:47 pm, Neelesh Bodas <[e-mail]:
On Jul 31, 4:51 am, jg <[e-mail]: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
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.

--
Ian Collins.

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.

[Andre Kostur]

jg <jg****@gmail.comwrote in news:1185839484.488728.323430
@b79g2000hse.googlegroups.com:

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.

[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.

[James Kanze]

On Aug 1, 7:44 pm, jg <[e-mail]:

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.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[jg]

On Aug 2, 1:26 am, James Kanze <[e-mail]:

On Aug 1, 7:44 pm, jg <[e-mail]:

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.

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

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.

[jg]

On Aug 3, 1:30 am, James Kanze <[e-mail]:

On Aug 2, 6:18 pm, jg <[e-mail]:

On Aug 2, 1:26 am, James Kanze <[e-mail]:

On Aug 1, 7:44 pm, jg <[e-mail]:
To summarize, C++ standard does not require that the
out-of-line code of aninlinefunctionbe 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 aninlinefunction, even there are
calls to thatinlinefunctionand those calls are not
inlined.

To clarify, I meant that C standard requires that the
out-of-line copy of anINLINEFUNCTIONmust 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 thatinlinefunction, if not
inlined, must be satisfied by an external definition of thatinline
functionin another translation unit.

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.

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 ofinlinefunction(C definesinline
functionin 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: "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)
<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).

JG

[James Kanze]

On Aug 3, 7:29 pm, jg <[e-mail]:

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.

--
James Kanze (GABI Software) email:james.kanze:gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[jg]

On Aug 4, 2:14 pm, James Kanze <[e-mail]:

On Aug 3, 7:29 pm, jg <[e-mail]:

Here is the text from C99, section 6.7.4 (6)
<quote>
Anyfunctionwith internal linkage can be aninlinefunction.
For afunctionwith external linkage, the following
restrictions apply: If afunctionis declared with aninline
functionspecifier, then it shall also be defined in the same
translation unit. If all of the file scope declarations for a
functionin a translation unit include theinlinefunction
specifier without extern, then the definition in that
translation unit is aninlinedefinition. Aninline
definition does not provide an external definition for the
function, and does not forbid an external definition in
another translation unit. Aninlinedefinition provides an
alternative to an external definition, which a translator may
use to implement any call to thefunctionin the same
translation unit. It is unspecified whether a call to the
functionuses theinlinedefinition 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).

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