question on inlining

[Peter Koch Larsen]

* ben:

[top-posting]

Please don't top-post in this group -- corrected.

James Daughtry:

Ok, now, under what circumstances should I flag the keyword inline? What
are
the likely candidates for inlining?

See Peter Koch Larsen's reply.

Do not rely on 'inline' as an optimization hint.

The keyword has nothing to do with optimization.

Isn't that putting it a little to strong. I believe the main objective
indeed was one of optimisation - this is how i recall Stroustrups
argumentation for these functions. The fact is that modern compilers
supposedly should be intelligent enough to have better judgment than the
programmer.

/Peter

 

[Alf P. Steinbach]

* Ioannis Vranos:

If you just want this, and you do not intend to inline, you can just make the function
static, and place its definition in the header.

No, you can't, in general.

With that approach you get multiple definitions (which take up space), and
you get different addresses for them, and they cannot be used as template
arguments.

That's part of why there is a keyword 'inline'.

However why would someone want to place a [non-template] function definition
in a header file?

Most importantly, for clarity.

Other reasons include documentation, avoiding needless separate compilation
(which includes build efficiency, but that can cut both ways), ease of
maintenance, habit and/or coding guidelines (especially in a multi-language
situation), and what I suspect is the most common, it's less to write.

 

[Ioannis Vranos]

No, you can't, in general.

With that approach you get multiple definitions (which take up space), and
you get different addresses for them, and they cannot be used as template
arguments.

Then if we want the same address, then why shouldn't we use one definition only?

That's part of why there is a keyword 'inline'.

I am not sure about this.

However why would someone want to place a [non-template] function definition
in a header file?

Most importantly, for clarity.

Other reasons include documentation,

Like?


avoiding needless separate compilation
(which includes build efficiency, but that can cut both ways),
ease of maintenance,

I am not sure I understand what this separate compilation part is about. Also, in the
contrary, if you decide to change only one function definition, you will have to recompile
every compilation unit that uses it, if you have made it inline.

habit and/or coding guidelines (especially in a multi-language
situation), and what I suspect is the most common, it's less to write.

I am not sure this "less to write" justifies such a use of inline.


I consider this approach as an abuse of the intended use, which can only result in more
bloated code, because of the inlining, and in most cases, as a consequence, more run-time
inefficiencies, by filling the CPU cache .

 

[Alf P. Steinbach]

* Ioannis Vranos:

Then if we want the same address, then why shouldn't we use one definition only?

You get more than one definition if the header file is included in more than
one compilation unit.

I am not sure about this.

I am.

However why would someone want to place a [non-template] function definition
in a header file?

Most importantly, for clarity.

Other reasons include documentation,

Like?

A header file serves as technical documentation of a logical module.

Especially for wrapper functions it's often a good idea to inline them,
so they'll be self-documenting.

When something can be expressed in code instead of comments or (worse)
separate documentation, it's usually preferable to use code -- for a
number of reasons.

I am not sure I understand what this separate compilation part is about. Also, in the
contrary, if you decide to change only one function definition, you will have to recompile
every compilation unit that uses it, if you have made it inline.

Yes, that's the "can cut both ways".

The advantage wrt. separate compilation is that with an 'inline' function in
a header file, there may be no need of an implementation file to be
separately compiled. That cuts down on both the programmer's work, on the
redundancy of declarations, and on the number of compiler invocations.

I am not sure this "less to write" justifies such a use of inline.

Often it does.

I consider this approach as an abuse of the intended use, which can only result in more
bloated code, because of the inlining, and in most cases, as a consequence, more run-time
inefficiencies, by filling the CPU cache .

That is incorrect. 'inline' does not (necessarily) inline: inlining or not
is up to the compiler's discretion, regardless of 'inline'. What 'inline'
does is to deal with multiple definitions for non-template code, which is a
correctness issue as opposed to an optimization issue.

 

[Alf P. Steinbach]

* Peter Koch Larsen:

* Alf P. Steinbach

Isn't that putting it a little to strong. I believe the main objective
indeed was one of optimisation - this is how i recall Stroustrups
argumentation for these functions. The fact is that modern compilers
supposedly should be intelligent enough to have better judgment than the
programmer.

Yes, you're technically right.

It's like stating "credit cards have nothing to do with breaking and
entering, they're for something else entirely", when a group of economics
students are discussing the merits and usage of credit cards and exclusively
focusing on their use for b&e, as if that's what they're for.

Although credit cards may have been originally designed as shimming
devices... ;-)

 

[E. Robert Tisdale]

Ok, now, under what circumstances should I flag the keyword inline?
What are the likely candidates for inlining?

All of them.

By now, it should be clear to you that
[automatic] inlining isn't really about optimization.
It's about encouraging *functional decomposition*
by assuring performance conscious programmers that
it isn't necessary to inline function *manually*.

The 'inline' qualifier is about *linkage* not optimization.
It tells the compiler to assure the link editor
that there is only *one* function definition
regardless of how many times the function definition
appears in object files that are linked together.

I try to make *all* functions inline functions
and let my optimizing compiler decide
which ones should actually be inline'd.

You need to ask yourself a question,

"Do I really care about performance?"

If you do, you will probably want to use
as many inline function definitions as possible.
You might consider taking advantage of both
inline *and* external function definitions:

cat file.h

#ifndef GUARD_FILE_H
#define GUARD_FILE_H 1

#ifdef EFINE_INLINE
inline
double f(double x) {
return x*(x + 2.0) + 1.0;
}
#else //EFINE_INLINE
double f(double x);
#endif//EFINE_INLINE
#endif//GUARD_FILE_H

cat file.cc

#undef EFINE_INLINE
#include "file.h"

double f(double x) {
return x*(x + 2.0) + 1.0;
}

g++ -DEFINE_INLINE -Wall -ansi -pedantic -O3 -c file.cc
nm --demangle file.o

00000000 T f(double)

This allows your inline and external function definitions
to coexist peacefully.
Use the -DEFINE_INLINE option only after you have finished
testing and debugging all of your code.
This will speed up the program development cycle
and allow you to optimize your code just before deployment.

 

[Ioannis Vranos]

You get more than one definition if the header file is included in more than
one compilation unit.

I was talking about one definition of a regular function inside an implementation file
only, and declaration in the header file.

A header file serves as technical documentation of a logical module.

Especially for wrapper functions it's often a good idea to inline them,
so they'll be self-documenting.

When something can be expressed in code instead of comments or (worse)
separate documentation, it's usually preferable to use code -- for a
number of reasons.

This is a tool subject, and the discussion turns to providing documentation by "hacking"
the language.


What kind of more technical documentation do you have in mind than this:


-- SomeFunc.h

// SomeFunc() does whatever
void SomeFunc();


-- SomeFunc.cpp

#include "SomeClass.h"

//...

void SomeFunc()
{
// ...
}



For something more, there are documentation tools out there (even for source code-level
documentation).

Yes, that's the "can cut both ways".

The advantage wrt. separate compilation is that with an 'inline' function in
a header file, there may be no need of an implementation file to be
separately compiled. That cuts down on both the programmer's work, on the
redundancy of declarations, and on the number of compiler invocations.

What kind of declarations does it cut down? As of compiler invocation, are you talking
about one additional file to compile while avoiding to recompile the rest when you decide
to change the definition, vs compile *all* the rest that make use of the function, once
you decide to modify the definition.

That is incorrect. 'inline' does not (necessarily) inline: inlining or not
is up to the compiler's discretion, regardless of 'inline'.

But it will inline whenever it can for the ones that you defined as inline and have placed
in scope before the function use in a translation unit, while it may not inline when you
make it a regular function with one definition in another translation unit.

In this way you will get more inlining, and not less.

What 'inline'
does is to deal with multiple definitions for non-template code, which is a
correctness issue as opposed to an optimization issue.

I am not sure I see any benefits of this. The way I view it, is that what you gain is only
extra pain to recompile everything on any change of the function definition as also
possible extra, unintended code bloat, while there isn't any source code benefit of this.

 

[Alf P. Steinbach]

* Ioannis Vranos:

I was talking about one definition of a regular function inside an
implementation file only, and declaration in the header file.

Sorry.

That is a non-existent case.

A function declared 'inline' must be declared 'inline' in all compilation
units where it's used, and it must be defined in all compilation units
(with that definition available to the compiler), and the definitions must
be the same -- i.e., in practice, if it is exposed via a declaration in
a header file, then it must be defined in a header file, and normally the
header file's declaration is also the definition.


[snipped the rest, based on misunderstanding of what 'inline' means]

 

[Ioannis Vranos]

Sorry.

That is a non-existent case.

A function declared 'inline' must be declared 'inline' in all compilation
units where it's used, and it must be defined in all compilation units
(with that definition available to the compiler), and the definitions must
be the same -- i.e., in practice, if it is exposed via a declaration in
a header file, then it must be defined in a header file, and normally the
header file's declaration is also the definition.

I was talking about the *non-inline*, regular functions case.

 

[John Carson]

* Peter Koch Larsen:


Yes, you're technically right.

It's like stating "credit cards have nothing to do with breaking and
entering, they're for something else entirely", when a group of
economics students are discussing the merits and usage of credit
cards and exclusively focusing on their use for b&e, as if that's
what they're for.

I gather that you think that the keyword inline is fundamentally about
avoiding multiple definitions. This strikes me as a very quirky
interpretation.

The fundamental purpose of the inline keyword is to suggest to the compiler
that it expand the function at the point where it is called and this is for
optimisation reasons.

Observe that multiple definitions are only a problem if the code defining a
function appears in two translation units and is not actually inlined. Thus
on your interpretation the fundamental purpose of the inline keyword is to
handle situations where functions are not inlined. This is bizarre. Avoiding
multiple definitions when a function is not inlined is an ancillary role of
inline, not its purpose.

Observe too that it is perfectly possible --- indeed common --- to define a
function in a cpp file for exclusive use within that cpp file. The inline
keyword in that context is for the sole purpose of suggesting that the
function be inlined within the cpp file; multiple definitions is not an
issue. The fact that the name of the keyword is "inline" is not accidental.

 

[Alf P. Steinbach]

* John Carson:

I gather that you think that the keyword inline is fundamentally about
avoiding multiple definitions. This strikes me as a very quirky
interpretation.

It's not an interpretation. It's the _only_ well-defined effect as per
§7.1.2 in the standard. How that hard fact strikes you is perhaps
interesting to you, but not to me.


[snipped nonsense]

The fact that the name of the keyword is "inline" is not accidental.

Probably not, but I'm not sure of the history here. One way I remember it
is that "inline" for C++ originally referred to "textually inline" for an
in-class member function definition. Another way I remember it it referred
to inline expansion of the generated machine code. The fact that the term
refers to "line" should favor textual inlining as the original meaning, but
perhaps that was a meaning before the C++ one. Consulting the original
edition of TCPPPL didn't clear up my memory, but the discussion there mostly
seems to indicate machine code inlining as the original meaning, while also
favoring the textual inline meaning here and there. So for that history of
the word someone with less Alzheimer's than me must step in.

 

[John Carson]

* John Carson:

It's not an interpretation. It's the _only_ well-defined effect as
per §7.1.2 in the standard.

Which means nothing. The purpose of inline is to suggest inline expansion.
The fact that it is only a suggestion doesn't disqualify this as inline's
purpose. Avoiding multiple definitions is simply a fall back so that the
code still "works" should inlining not take place.

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

I rest my case.

 

[John Carson]

Avoiding multiple definitions is simply a
fall back so that the code still "works" should inlining not take
place.

In case my meaning here is not clear: if the code is actually inlined, then
the object code doesn't contain a function definition at all, so the issue
of multiple definitions never arises.

 

[Alf P. Steinbach]

* John Carson:

Which means nothing. The purpose of inline is to suggest inline expansion.
The fact that it is only a suggestion doesn't disqualify this as inline's
purpose.

Talking about purpose, someone unknown's unknown intention, is religious.

Talking about what is well-defined, what it can be practically used for, is
less unproductive.

Avoiding multiple definitions is simply a fall back so that the
code still "works" should inlining not take place.

Well, a car's ability to move is just a fall back so that it can still be
used as a sleeping place in case the current position is untenable. That's
obvious since the main purpose of a car is as a sleeping place.

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

I rest my case.

And good is that.

The quoted para leaves machine code inlining entirely up to the compiler,
for each call of the function, irrespective of 'inline' or not (using the
function's address, however, will in practice zero the inlining potential).

The only well-defined effect is that at the end that "the other rules ...
shall still be respected", those rules being about multiple definitions.

 

[richa]

According to the C++ standard, inlining is at the discretion of the
compiler. It might thus inline a function that is not marked as "inline" and
it might not inline a function marked as "inline". Various compilers allow
you to override that one way or another, e.g. by using compilerswitches or
by using special keywords such as __forceinline.
The purpose of inline for the user point of view is to avoid errors with
multiple definitions.

/Peter

so peter u want to say that inline keyword is useless or ..what?
uptil now what i have studied is that to make a function inline u have
add inline keyword to it...compilers are mot smart enough to do that
...or is it?
it may be but i don't know..if it's possible then plz give me detailed
information about it.

 

[richa]

According to the C++ standard, inlining is at the discretion of the
compiler. It might thus inline a function that is not marked as "inline" and
it might not inline a function marked as "inline". Various compilers allow
you to override that one way or another, e.g. by using compilerswitches or
by using special keywords such as __forceinline.
The purpose of inline for the user point of view is to avoid errors with
multiple definitions.

/Peter

so peter u want to say that inline keyword is useless or ..what?
uptil now what i have studied is that to make a function inline u have
add inline keyword to it...compilers are not smart enough to do that
...or is it?
it may be but i don't know..if it's possible then plz give me detailed
information about it.

 

[Geo]

This thread seems to have lost it's way, I think we are nit picking the
route, but missing the destination.

'inline' prevents multiple definition errors, yes, but why would we be
getting multiple definitions in the first place?
We get them because we've made the same code visible in multiple
translation units.

Why have we done that ?
We've done that so that compiler can see the source for the function in
each translation unit.

So why have we done that?
Because we want to give the compiler the opportunity to inline the
code, and it can't do that unless it can see the source.

Yes, the compiler is free to ignore 'inline' requests, and it's free to
inline any function it likes, provided it is able to see the source
within the translation unit.

 

[Peter Koch Larsen]

so peter u want to say that inline keyword is useless or ..what?
uptil now what i have studied is that to make a function inline u have
add inline keyword to it...compilers are not smart enough to do that
..or is it?
it may be but i don't know..if it's possible then plz give me detailed
information about it.

Hi Richa

Nope - i do not say that inlining is a useless word. On some compilers, I'm
quite sure that inlining is better handled by the programmer so the "inline"
keyword is also a suggestion to the compiler. What i meant in my previous
post was that according to the C++ standard, there is no mention of what
happens under the covers. Any compiler that complies with the standard is
free to do as i mentioned.
In the "real" world, the compiler gives you an option about how to handle
inlined functions. But that was not what you asked about ;-)

/Peter

 

[Jacques Labuschagne]

so peter u want to say that inline keyword is useless or ..what?
uptil now what i have studied is that to make a function inline u have
add inline keyword to it...compilers are mot smart enough to do that
..or is it?
it may be but i don't know..if it's possible then plz give me detailed
information about it.

The point is that inline is just a hint. It increases that function's
chances of being inlined, but it's not a guarantee. It is useful because
it tells the compiler more about what you're trying to achieve.

Jacques.

 

[Alf P. Steinbach]

* Geo:

This thread seems to have lost it's way, I think we are nit picking the
route, but missing the destination.

'inline' prevents multiple definition errors, yes, but why would we be
getting multiple definitions in the first place?
We get them because we've made the same code visible in multiple
translation units.
Right.


Why have we done that ?
We've done that so that compiler can see the source for the function in
each translation unit.

Generally wrong.

I mentioned a few reasons on request from Ioannis in this thread.

Forgot one important there: the trend towards template oriented programming.