How does inlining work?

[Generic Usenet Account]

While I have a very good feel for how inlining works, I fail to see how
in the world inlining can work if the inlined function is not described
"in place" in a header file, but rather defined in a separate source
file (using the inline keyword), which gets linked in? Does inling
work at all in such cases? If it does, can someone kindly explain how
the compilers handle that? If it does not, is that documented
somewhere?

Thanks,
Gus

[David White]

Generic Usenet Account wrote:

While I have a very good feel for how inlining works, I fail to see
how in the world inlining can work if the inlined function is not
described "in place" in a header file, but rather defined in a
separate source file (using the inline keyword), which gets linked
in? Does inling work at all in such cases? If it does, can someone
kindly explain how the compilers handle that? If it does not, is
that documented somewhere?

The definition of an inline function must be present and must be identical
in every translation unit (i.e., source file) in which it is called. If you
call an inline function in multiple source files the obvious way to do this
is to place the definition in a header file and #include the header in each
of the source files, but if you want, which you probably don't, you can
explicitly define the function separately and identically in each source
file.

I sometimes place an inline function in a source file rather than a header
file if I don't use it anywhere else (e.g., a private class member
function).

DW

[Greg]

Generic Usenet Account wrote:

While I have a very good feel for how inlining works, I fail to see how
in the world inlining can work if the inlined function is not described
"in place" in a header file, but rather defined in a separate source
file (using the inline keyword), which gets linked in? Does inling
work at all in such cases? If it does, can someone kindly explain how
the compilers handle that? If it does not, is that documented
somewhere?

Thanks,
Gus

No, the inline keyword alone is not enough to let a function call be
inlined.

In order to inline a function the compiler must also have the
function's implementation on hand. For this reason inline functions are
declared in header files. If the compiler has not seen the inlined
function's body when it compiles a call to that function, the function
call will not be inlined.

Failing to inline a function call is not considered an error; generally
there wil be no indication that a function call was not inlined. But
most C++ compilers have a setting to report an error whenever the
compiler was unable to inline a function.

Greg

[Alf P. Steinbach]

* Generic Usenet Account:

While I have a very good feel for how inlining works,
Uh, you don't. ;-)

I fail to see how
in the world inlining can work if the inlined function is not described
"in place" in a header file, but rather defined in a separate source
file (using the inline keyword), which gets linked in?
That is not allowed.

Does inling work at all in such cases?
If you remove the 'inline' keyword so as to get a conforming program text,
then yes, it can work. That's called "whole program optimization", or "global
optimization". For example, Visual C++ from Microsoft does this.

If it does, can someone kindly explain how the compilers handle that?
Generally it's the linker that takes care of this job, because only the linker
has the necessary information available. If or when we get modules into the
language, possibly in C++0x, the compiler may be able to contribute more. Or
not, depending on how the standardization process turns out.

If it does not, is that documented somewhere?

If you mean, whether your invalid use of the 'inline' keyword is documented as
invalid anywhere, then that's the C++ standard. If you mean, is whole program
optimization documented somewhere, that'll be your compiler's documentation.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Nimmi Srivastav]

Alf P. Steinbach wrote:

I fail to see how
in the world inlining can work if the inlined function is not described
"in place" in a header file, but rather defined in a separate source
file (using the inline keyword), which gets linked in?

That is not allowed.

I disagree. This is most certainly allowed by most compilers ----
whether it works or not as desired is a different issue altogether!

Thanks,
Nimmi

[Alf P. Steinbach]

* Nimmi Srivastav:

Alf P. Steinbach wrote:

I fail to see how
in the world inlining can work if the inlined function is not described
"in place" in a header file, but rather defined in a separate source
file (using the inline keyword), which gets linked in?

That is not allowed.

I disagree.

Seemingly you don't understand that this is a matter of _fact_, as opposed to
a matter of opinion. So, cough up chapter and verse from the standard.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[persenaama]

> So, cough up chapter and verse from the standard.

I thought you knew already where in the standard that is as it looks
like you just read the chapter and verse carefully no doubt.

To Nimmi: please can you give a quote too as I'm handicapped by lack of
the standard document at the moment as I didn't have the foresight to
copy the file to my laptop before traveling. :)

I don't remember it being undefined to have inline specifier in
function or method declaration, but then again, the standard is over
700 pages.. <- sorry, I am just a human being and not have a perfect
memory STILL I work writing software sometimes in c++, does that make
_me_ incompetent? Should I resign now? Anyway, since the topic popped
up curious to get the topic laid to rest with facts. Thanks guys,
whoever helps me first. ;----)

[David White]

"persenaama " <ju***@liimatta .org> wrote in message
news:11******** **************@ g14g2000cwa.goo glegroups.com.. .

So, cough up chapter and verse from the standard.
I thought you knew already where in the standard that is as it looks
like you just read the chapter and verse carefully no doubt.

To Nimmi: please can you give a quote too as I'm handicapped by lack of
the standard document at the moment as I didn't have the foresight to
copy the file to my laptop before traveling. :)

* * * * *
7.1.2
2 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.

3 A function defined within a class definition is an inline function. The
inline specifier shall not appear on a block scope function declaration.(79 )

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

The reference to external linkage doesn't make sense to me yet. TC++PL 3rd
Ed. says (p. 199) that the "combinatio n 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; }
I don't remember it being undefined to have inline specifier in
function or method declaration, but then again, the standard is over
700 pages.. <- sorry, I am just a human being and not have a perfect
memory STILL I work writing software sometimes in c++, does that make
_me_ incompetent? Should I resign now? Anyway, since the topic popped
up curious to get the topic laid to rest with facts. Thanks guys,
whoever helps me first. ;----)

DW

[persenaama]

Thanks for the quote, it takes a couple of readings to decrypt what
they intended to say, actually I still didn't quite get what their
*intention* was but according to these rules what mr. Stenbach says is
not strictly incorrect.. as long as the *definition* is inline in every
translation init all's well as far as the standard is concerned.

Quote from the quote (thanks!): "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."

The keyword here is *declared*, declared.. that will hold up true
indeed if the same header is included in other translation units (note:
I am not claiming that files or headers exist they are just figment of
implementations imagination ;-) So far so good, the original poster's
hypothesis (?) doesn't invalidate this rule..

Earlier in the same paragraph this is stated:

"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)."

Indeed, if the *definition* is in other translation unit, in this case
I read between the lines that in a different sourcefile (okay, again,
implementation specific detail but that's how I interpreted the
original post, call me incompetent ;) So far again I don't see any
gross neglegance or violation of the standard in the original post,
just construct which requires every other translation unit to have the
*same* definition, this is rather difficult to enforce unless the same
sourcecode is part of the other translation units being compiled. The
common method to achieve this is to put the inline code in a header
file, often the declaration and definition are the same thing.. or the
definition comes later in the same file, or, separate implementation
file is used, .inl is what I encountered myself now and then (not my
sourcecode heaven's sake, I combine the definition with declaration
more often than not :)

All in all, I don't seem to see where the actual error is, I only see
where it could possibly be but w/o any actual sourcecode to discuss..

The example you posted is a good case, btw. Side effects, linkage,
undefined behaviour and such aside, one way I can see this could be
implemented without much fuss is that the compiler merely ignores the
inline keyword. It's free to do so at any time of it's liking for code
generation purposes anyhow. The only difficulty is that the standard
itself disagrees (?) with the TC++PL.. I'd say I'd trust the standard
more in this case as that's what all implementations are supposed to be
implementing (?) I'm very likely to be wrong since I am way out of my
league here.. but I got asshole and I got opinions and this is a
discussion group so there! ;-)

[msalters]

persenaama schreef:

Thanks for the quote, it takes a couple of readings to decrypt what
they intended to say, actually I still didn't quite get what their
*intention* was but according to these rules what mr. Stenbach says is
not strictly incorrect.. as long as the *definition* is inline in every
translation init all's well as far as the standard is concerned.
You are aware that every definition is also a declaration? There's
no word for declarations-that-aren't-definitions, although "forward
declaration" comes close.

The only difficulty is that the standard
itself disagrees (?) with the TC++PL.. I'd say I'd trust the standard
more in this case as that's what all implementations are supposed to be
implementing (?)

Assuming you have a 3rd ed, there is no disagreement. And yes,
implementations are supposed to implement the standard. Mr. Stroustrup
has very good ideas, but he isn't the ultimate authority.

HTH,
Michiel Salters