question on inlining

The inline keyword is a hint, just like register. The compiler is free
to ignore it entirely. As such, functions without an inline keyword (or
defined outside of a class declaration) may be inlined if it meets some
unspecified internal heuristics. How a compiler optimizes code is
implementation-dependent.

Jul 23 '05 #3

ben wrote:

is it true that a function without an inline keyword never get inlined? If
not true when is it inlined or not?

A compiler is free to inline whatever function it wants. Keyword inline is provided
because compilers aren't smart enough in general, and a user can aid the compiler to this
(but still the compiler is free to ignore the suggestion).

--
Ioannis Vranos

http://www23.brinkster.com/noicys

Jul 23 '05 #4

ben

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

ben

"James Daughtry" <mo*******@hotmail.com> wrote in message
news:11*********************@g43g2000cwa.googlegro ups.com...

The inline keyword is a hint, just like register. The compiler is free
to ignore it entirely. As such, functions without an inline keyword (or
defined outside of a class declaration) may be inlined if it meets some
unspecified internal heuristics. How a compiler optimizes code is
implementation-dependent.

Jul 23 '05 #5

ben wrote:

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

We use inline to avoid the time cost of continuous function calls. In general, the usual
candidates are frequently called, small functions.

--
Ioannis Vranos

http://www23.brinkster.com/noicys

Jul 23 '05 #6

* ben:

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

James Daughtry:
The inline keyword is a hint, just like register. The compiler is free
to ignore it entirely. As such, functions without an inline keyword (or
defined outside of a class declaration) may be inlined if it meets some
unspecified internal heuristics. How a compiler optimizes code is
implementation-dependent.

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.

--
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?

Jul 23 '05 #7

lilburne

ben wrote:

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

Use inline when your profiler indicates that having the function outline
is a bottleneck. As someone said small functions called within tight
loops are a potential candidate, but small functions per se aren't.

Jul 23 '05 #8

Chris Theis

"ben" <be******@hotmail.com> wrote in message
news:42**********************@news.optusnet.com.au ...

is it true that a function without an inline keyword never get inlined? If
not true when is it inlined or not?

ben

A function can be inlined either by indicating the word inline or if it is
defined in the context of the class definition. As already pointed out by
others the keyword is simply a hint for the compiler, although if I recall
correctly there were old compilers that did not inline functions that were
not explicitly flagged with inline. For a more in-depth discussion what can
be inlined and what the compiler has to consider you can take a look at the
posting "How to force 'inline' with GCC or ICC" originating around the 15th
of May.

HTH
Chris

Jul 23 '05 #9

> What are the likely candidates for inlining?
Teeny tiny functions that would otherwise be written inline if there
weren't a need for some form of genericity. Follow this link for a
detailed analysis of why to avoid inline until you know that it buys
you something:

http://www.gotw.ca/gotw/033.htm

Jul 23 '05 #10

Lionel B

"Peter Koch Larsen" <pk*****@mailme.dk> wrote in message news:aE********************@news000.worldonline.dk ...

"ben" <be******@hotmail.com> skrev i en meddelelse
news:42**********************@news.optusnet.com.au ...
is it true that a function without an inline keyword never get inlined? If
not true when is it inlined or not?

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

Indeed. So - at least with modern compilers - inline as a keyword (or by function definition within class declaration)
would seem to be redundant as an optimisation tool.

[...]

The purpose of inline for the user point of view is to avoid errors with
multiple definitions.

This has always seemed curious to me... can one not generally avoid multiple definition by declaring functions static
where appropriate, or simply by better organisation of header files/compilation units? That is, are there really
situations where declaring a function inline is the *only* reasonable means of circumventing mutiple definition? I can't
think of one offhand (but then I'm not thinking terribly well today).

--
Lionel B

Jul 23 '05 #11

* James Daughtry:

What are the likely candidates for inlining?

Teeny tiny functions that would otherwise be written inline if there
weren't a need for some form of genericity. Follow this link for a
detailed analysis of why to avoid inline until you know that it buys
you something:

http://www.gotw.ca/gotw/033.htm

The GOTW does not support your (erronous) conclusion.
--
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?

Jul 23 '05 #12

Erroneous how? Aside from not listing every possible situation that you
might want to inline for brevity, my only conclusion was that it should
be avoided until you know that it's beneficial. Judging from this:

Just Say 'No For Now'
And this:
- avoid inlining or detailed tuning until performance profiles prove the need
And this:
- corollary: in general, avoid inlining

I would say that the GOTW supports my conclusion to the letter.
Obviously you're talking about some miniscule detail of my post, so
please let me know what it was so that I can be more detailed next time.

Jul 23 '05 #13

Victor Bazarov

James Daughtry wrote:

The inline keyword is a hint, just like register. The compiler is free
to ignore it entirely. As such, functions without an inline keyword (or
defined outside of a class declaration) may be inlined if it meets some
unspecified internal heuristics. How a compiler optimizes code is
implementation-dependent.

There is one important difference, though. If you *define* your function
in a header without declaring it 'inline' and then include that header in
more than one module, you break the ODR. If the function is declared
'inline', that doesn't happen even if the compiler does not inline it in
all the cases (and instead creates a body somewhere).

V

Jul 23 '05 #14

* James Daughtry:

I would say that the GOTW supports my conclusion to the letter.
Obviously you're talking about some miniscule detail of my post, so
please let me know what it was so that I can be more detailed next time.
OK.

"ben" asked: Ok, now, under what circumstances should I flag the keyword inline? What are
the likely candidates for inlining?
James Daughtry answered, possibly only to the latter question:Teeny tiny functions that would otherwise be written inline if there
weren't a need for some form of genericity.

A correct partial answer to the first question is: when it's needed to avoid
multiple definitions.

Where to place the keyword is then a matter of personal preference, but the
FAQ has some advice: <url:
http://www.parashift.com/c++-faq-lite/inline-functions.html#faq-9.9>.

A correct approach to the second question is to first note that inlining has
very little to do with the keyword 'inline'. If the meaning of the question
is "what are the likely candidates for using the keyword 'inline'" then the
answer is the same as for the first question. If the meaning is which
functions should one force to be inline, using some compiler-specific
mechanism (which might involve the keyword, or not), then the only possible
answer is "where measurements show that it yields a needed improvement that
is great enough compared to the costs", where the costs may include extra
dependencies in the code. If the meaning is which functions will the
compiler probably inline, then the answer is that it depends on the full
source code, the compiler, the compiler version, the compiler options, and
possibly other things: there is generally no way for us to predict.

None of these possible meanings and corresponding answers involve "tiny
functions that would otherwise be written inline if there weren't a need for
some genericity", and genericity has nothing to do with inlining of tiny
functions, or not (there is a vague association in that genericity can be
used as an alternative to 'inline' and can solve some multiple definition
problems that 'inline' can not, but that's another kettle of fish).

Perhaps there is a possible meaning that I've overlooked, but I doubt it.

--
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?

Jul 23 '05 #15

* Victor Bazarov:

James Daughtry wrote:
The inline keyword is a hint, just like register. The compiler is free
to ignore it entirely. As such, functions without an inline keyword (or
defined outside of a class declaration) may be inlined if it meets some
unspecified internal heuristics. How a compiler optimizes code is
implementation-dependent.

There is one important difference, though. If you *define* your function
in a header without declaring it 'inline' and then include that header in
more than one module, you break the ODR. If the function is declared
'inline', that doesn't happen even if the compiler does not inline it in
all the cases (and instead creates a body somewhere).

Nit-picking (it probably seems as if I'm picking many nits with your
postings lately, but that's just because you give good answers where
nit-picking is of value; I don't pick nits with ungood postings):

Nit: "compilation unit", not "module" (although "module" is not clearly
defined by anyone for C++, IMO it gives the wrong impression here).

Cheers,

- Alf

--
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?

Jul 23 '05 #16

It was apparently poor wording on my part. I'll use legalese from now
on to avoid that. Sorry.

Jul 23 '05 #17

Victor Bazarov wrote:

There is one important difference, though. If you *define* your function
in a header without declaring it 'inline' and then include that header in
more than one module, you break the ODR. If the function is declared
'inline', that doesn't happen even if the compiler does not inline it in
all the cases (and instead creates a body somewhere).

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.

However why would someone want to place a function definition in a header file?

--
Ioannis Vranos

http://www23.brinkster.com/noicys

Jul 23 '05 #18

Ioannis Vranos wrote:

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.

Or better, place it inside an anonymous namespace.

However why would someone want to place a function definition in a
header file?

--
Ioannis Vranos

http://www23.brinkster.com/noicys

Jul 23 '05 #19

Peter Koch Larsen

"Alf P. Steinbach" <al***@start.no> skrev i en meddelelse
news:42****************@news.individual.net...

* ben:
[top-posting]
Please don't top-post in this group -- corrected.

James Daughtry:
> The inline keyword is a hint, just like register. The compiler is free
> to ignore it entirely. As such, functions without an inline keyword (or
> defined outside of a class declaration) may be inlined if it meets some
> unspecified internal heuristics. How a compiler optimizes code is
> implementation-dependent.

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
--
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?

Jul 23 '05 #20

* Ioannis Vranos:

Victor Bazarov wrote:
There is one important difference, though. If you *define* your function
in a header without declaring it 'inline' and then include that header in
more than one module, you break the ODR. If the function is declared
'inline', that doesn't happen even if the compiler does not inline it in
all the cases (and instead creates a body somewhere).

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.

--
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?

Jul 23 '05 #21

Andre Kostur

Ioannis Vranos <iv*@remove.this.grad.com> wrote in
news:1116970709.809548@athnrd02:

Victor Bazarov wrote:
There is one important difference, though. If you *define* your
function in a header without declaring it 'inline' and then include
that header in more than one module, you break the ODR. If the
function is declared 'inline', that doesn't happen even if the
compiler does not inline it in all the cases (and instead creates a
body somewhere).

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.

However why would someone want to place a function definition in a
header file?

So that you have a consistent definition of the function in every
compilation unit that includes that header (and for some strange reason
they _don't_ want them all calling the same function body....?!? Perhaps a
separate copy of static local variables for each compilation unit?)

Jul 23 '05 #22

Alf P. Steinbach wrote:

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.

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 .

--
Ioannis Vranos

http://www23.brinkster.com/noicys

Jul 23 '05 #23

* Ioannis Vranos:

Alf P. Steinbach wrote:
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.

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.

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

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.

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.

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.

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.

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.

--
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?

Jul 23 '05 #24

* Peter Koch Larsen:

* Alf P. Steinbach

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.

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

--
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?

Jul 23 '05 #25

E. Robert Tisdale

ben wrote:

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.

Jul 23 '05 #26

Alf P. Steinbach wrote:

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

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.

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.

--
Ioannis Vranos

http://www23.brinkster.com/noicys

Jul 23 '05 #27

* Ioannis Vranos:

* Alf P. Steinbach wrote:
* 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 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]

--
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?

Jul 23 '05 #28

Alf P. Steinbach wrote:

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.

--
Ioannis Vranos

http://www23.brinkster.com/noicys

Jul 23 '05 #29

John Carson

"Alf P. Steinbach" <al***@start.no> wrote in message
news:42****************@news.individual.net

* Peter Koch Larsen:
* Alf P. Steinbach

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.

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.

--
John Carson

Jul 23 '05 #30

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

--
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?

Jul 23 '05 #31

John Carson

"Alf P. Steinbach" <al***@start.no> wrote in message
news:42****************@news.individual.net

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

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

Jul 23 '05 #32

John Carson

"John Carson" <jc****************@netspace.net.au> wrote in message
news:d7***********@otis.netspace.net.au

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.

--
John Carson

Jul 23 '05 #33

* John Carson:

"Alf P. Steinbach" <al***@start.no> wrote in message
news:42****************@news.individual.net
* 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.

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.

--
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?

Jul 23 '05 #34

richa

Peter Koch Larsen wrote:

"ben" <be******@hotmail.com> skrev i en meddelelse
news:42**********************@news.optusnet.com.au ...
is it true that a function without an inline keyword never get inlined? If
not true when is it inlined or not?

ben

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.

Jul 23 '05 #35

richa

Peter Koch Larsen wrote:

"ben" <be******@hotmail.com> skrev i en meddelelse
news:42**********************@news.optusnet.com.au ...
is it true that a function without an inline keyword never get inlined? If
not true when is it inlined or not?

ben

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.

Jul 23 '05 #36

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.

Jul 23 '05 #37

Peter Koch Larsen

"richa" <st********@yahoo.co.in> skrev i en meddelelse
news:11*********************@g44g2000cwa.googlegro ups.com...

Peter Koch Larsen wrote:
"ben" <be******@hotmail.com> skrev i en meddelelse
news:42**********************@news.optusnet.com.au ...
> is it true that a function without an inline keyword never get inlined?
> If
> not true when is it inlined or not?
>
> ben
>
>

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.

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

Jul 23 '05 #38

Jacques Labuschagne

richa wrote:

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.

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.

Jul 23 '05 #39

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

--
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?

Jul 23 '05 #40

Geo

Alf P. Steinbach wrote:

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

Really, why else then ?

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

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

Yes, of course, but 'inline' predates 'template', nevertheless, the
template code is only included in multiple translation units for the
same reason, the compiler NEEDS to see it.

Jul 23 '05 #41

* Geo:

Alf P. Steinbach wrote:
* 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.

Really, why else then ?

See my (first) reply to Ioannis:

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

--
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?

Jul 23 '05 #42

Class that cannot be inherited ... C++

Alf P. Steinbach wrote:

Generally wrong.

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

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

Still, I am not satisfied by the answers. :-)

If you may clarify to these, it would be great:

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

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.

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 inlined function definition as
also possible extra, unintended code bloat, while there isn't any source code benefit of this.

--
Ioannis Vranos

http://www23.brinkster.com/noicys

Jul 23 '05 #43

wht is ODR ?
what i guess with that is this
please reply after filter out my mistake

"
if in header file function body is given and it is not mentioned inline
so that function will be compiled again and again. and waste compliler
resource .
now what the sffect on code will be thr.
what i knows about header is that a function / class after compilation
will be in a obj file and a header file is for tell ur program the
signature of the functions at compile time . so if body of a function
is defined in the header file so how will it affect the compilation
process and that precomplied object file (.obj or .o)

Jul 23 '05 #44

Geo

Alf P. Steinbach wrote:

* Geo:
Alf P. Steinbach wrote:
* 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.

Really, why else then ?

See my (first) reply to Ioannis:

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

Sorry, but I can't see any other reason, the ONLY reason to include the
function source in a translation unit is for the compiler to see it,
and it only needs to see it more than once is if it's a candidate for
inlining, or it's a template.

Jul 23 '05 #45

Class that cannot be inherited ... C++

See Peter Koch Larsen's reply.

Do not rely on 'inline' as an optimization hint.
The keyword has nothing to do with optimization.
--
will u plese coorect me
properly inlineD code will help the compiler to waste less resources to
compile
or it give work to complier that inline is mentioned so go and cheack
it can be inlined or not.
now in both case
if in will make inline
so will save the execution time ata least
secondly
if we r not mentioning inline for a function so it will never make it
inline why?

Jul 23 '05 #46

* Ioannis Vranos:

Alf P. Steinbach wrote:
Generally wrong.

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

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

Still, I am not satisfied by the answers. :-)

If you may clarify to these, it would be great:

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

Parse error.

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()
{
// ...
}
Remove

* The comment (can't be checked by the compiler)
* The #include.
* The repeated declaration of the function signature.

Move

* The body of the function to the header file.

Add

* 'inline'.

Now the function (assuming it's a small one) is self-documenting.

For something more, there are documentation tools out there (even for source code-level
documentation).
The main documentation is always the compilable source code. Comments
are second class, because they can't be checked and easily get out of
synch in the cases where they're correct in the first place. Separate
documentation is even worse.

> > I am not sure I understand what this separate compilation part
is about.

When you only have a header file, no implementation file, there is one
less file to compile separately.
[Below it seems something's wrong with the quoting levels. However]

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.
What kind of declarations does it cut down?

It cuts down on _redundancy_ of declarations, the repeated function
signatures.

Redundancy is bad both because of more work, and because of the
possibility of unnoticed differences.

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.
Parse error. I gather it's an attempt at phrasing a false dilemma? ;-)

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,

No, that is incorrect.

The point that's been stressed (I feel) a thousand times in this thread
is that not only can you not rely on that.

With modern compilers you can rely on the opposite: that the compiler
will do the job much better you can, and the more information you give
the compiler to do that job, the better job it does.

while it may not inline when you
make it a regular function with one definition in another
translation unit.
That's almost a given as of 2005, because few C++ compilers so far
do a decent "whole program optimization" which is needed for that.

Essentially that, for those hooked on needless optimization, one should
give the compiler the most information possible to do the very best job.

And that means preferably using 'inline' functions and in-class definitions.
:-)

Lest I be misunderstood here: I'm not recommending that unconditionally,
only for the mindless micro-optimization-freaks.

In this way you will get more inlining, and not less.
The effect depends on everything. The complete program, the compiler,
system, options, everything. All you know is that _whatever_ you're asking
the compiler to optimize for, the more information you make available to it
(like the source code of functions), the better a job it will generally do.

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

Naturally: if the code doesn't need to be correct it can be infinitely
optimized! Great idea. Correctness, goodbye!

The way I view it, is that what you gain is only
Incorrect.

extra pain to recompile everything on any change of the inlined
function definition
Yes, there I agree very much.

as also possible extra, unintended code bloat,
Nope. Or rather, anything's possible, but it's extremely unlikely. On
the contrary, if you the compiler to optimize for code space, it's much
more likely to do a perfect job if you give it maximum information.

while there isn't any source code benefit of this.

Incorrect.
Cheers,

- Alf

--
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?

Jul 23 '05 #47

velthuijsen

Class that cannot be inherited ... C++ wrote:

See Peter Koch Larsen's reply.

Do not rely on 'inline' as an optimization hint.
The keyword has nothing to do with optimization.
--
will u plese coorect me
properly inlineD code will help the compiler to waste less resources to
compile Read: http://www.gotw.ca/gotw/033.htm
or it give work to complier that inline is mentioned so go and cheack
it can be inlined or not.
now in both case Yes it is no more then a hint for the compiler to check if it can be
inlined.
if in will make inline
so will save the execution time ata least Read the caveat about inlining in the article.
secondly
if we r not mentioning inline for a function so it will never make it
inline why?

The keyword inline has another effect (besides hinting that you as
programmer would like to see the function inlined).
The code that you want to inline has to be visible in every
file/compilation unit that you use this code in.
If you do this with a normal function you get a linker error saying
that your function is already defined
try the following bit:

Expand|Select|Wrap|Line Numbers

 
Header file: Foo.h

#ifndef FOO_H

#define FOO_H
 
void Bar(){static int x =0;++x;}
 
void Test();

#endif
 
code file: Foo.cpp

#include "Foo.h"

void Test()

{

Bar();

}
 
main: main.cpp

#include "Foo.h"

#include <iostream>
 
int main()

{

std::cout << getchar();

return 0;

}

This should get you the error.
This happens because basically the content of the header file gets
placed at the exact point where you do #include "Foo.h". This results
in the linker finding the function Bar twice.
If the words inline gets placed before the function Bar and it gets
inlined by the compiler the function Bar does not exist.
Since you cannot say 100% sure when a function gets inlined (the
compiler makes the final decision) the linker ignores multiple
definitions of the same function if the function has the inline keyword
infront of it.
In both cases the problem of multiple definitions is (re)solved.

Jul 23 '05 #48