question on inlining

[ben]

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

ben

 

[Peter Koch Larsen]

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

 

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

 

[Ioannis Vranos]

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

 

[ben]

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

ben

 

[Ioannis Vranos]

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.

 

[Alf P. Steinbach]

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

 

[Chris Theis]

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

 

[lilburne]

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.

 

[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

 

[Lionel B]

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

 

[Alf P. Steinbach]

* James Daughtry:

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.

 

[James Daughtry]

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.

 

[Victor Bazarov]

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

 

[Alf P. Steinbach]

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

 

[Alf P. Steinbach]

* Victor Bazarov:

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

 

[James Daughtry]

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

 

[Ioannis Vranos]

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]

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.

 

[Andre Kostur]

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