Inline functions

[Suresh V]

I believe inline functions are expanded inline instead of called. For
below code if inline function are expanded in place then output that i
have to see should be : {1st all constructor's has to be called then
destructor of constructed objected in reverse}
constructor called
constructor called
constructor called
destructor called
destructor called
destructor called

Please explain what is the reason for this result .

For below code

#include <stdio.h>
#include <iostream>

class A{
public:
A::A() {
std::cout << "constructor called" << std::endl;
}
A::~A() {
std::cout << "destructor called" << std::endl;
}

void createObj() {
A a;
}
};

int main(){
A b;
b.createObj();
A c;
return 0;
}

Output:
constructor called
constructor called
destructor called
constructor called
destructor called
destructor called

This output infers that inline function is still not expanded.

 

[Vladimir Jovic]

I believe inline functions are expanded inline instead of called. For
below code if inline function are expanded in place then output that i
have to see should be : {1st all constructor's has to be called then
destructor of constructed objected in reverse}

Your believe is wrong.

constructor called
constructor called
constructor called
destructor called
destructor called
destructor called

Please explain what is the reason for this result .

That's correct behaviour of your example.

For below code

#include <stdio.h>
#include <iostream>

class A{
public:
A::A() {
std::cout << "constructor called" << std::endl;
}
A::~A() {
std::cout << "destructor called" << std::endl;
}

void createObj() {
A a;
}
};

int main(){
A b;
b.createObj();
A c;
return 0;
}

Output:
constructor called
constructor called
destructor called
constructor called
destructor called
destructor called

This output infers that inline function is still not expanded.

Check the assembler code whether the functions really got inlined.

 

[Fred Zwarts]

I believe inline functions are expanded inline instead of called. For
below code if inline function are expanded in place then output that i
have to see should be : {1st all constructor's has to be called then
destructor of constructed objected in reverse}
constructor called
constructor called
constructor called
destructor called
destructor called
destructor called

Please explain what is the reason for this result .

For below code

#include <stdio.h>
#include <iostream>

class A{
public:
A::A() {
std::cout << "constructor called" << std::endl;
}
A::~A() {
std::cout << "destructor called" << std::endl;
}

void createObj() {
A a;
}
};

int main(){
A b;
b.createObj();
A c;
return 0;
}

Output:
constructor called
constructor called
destructor called
constructor called
destructor called
destructor called

This output infers that inline function is still not expanded.

1) I couldn't find an inline function in your code.

2) inline is an optimization hint for the compiler, which the compiler may ignore.
The compielr may also optimize functions inline without the inline keyword.
More important is that an inline function can be specified more than one compilation unit,
which means that it can be placed in a header file.

3) When a compiler inlines the body of a function, this includes the destruction of
objects within the scope of a function body. So, it does not make any difference
with respect to the order of the execution of constructors and/or destructors.

 

[Suresh V]

1) I couldn't find an inline function in your code.

Functions which are defined with in a class are by default inline.

2) inline is an optimization hint for the compiler, which the compiler may ignore.
The compielr may also optimize functions inline without the inline keyword.
More important is that an inline function can be  specified more than one compilation unit,
which means that it can be placed in a header file.

3) When a compiler inlines the body of a function, this includes the destruction of
objects within the scope of a function body. So, it does not make any difference
with respect to the order of the execution of constructors and/or destructors.

Inline function are compiler optimization in that case all the content
of the inline function has to be copied to the place where it is
called. So why should scope of function body still have to be
preserved.

int main(){
A b;
A a; // Content of createObj;
A c;
return 0;
}

 

[Ian Collins]

Inline function are compiler optimization in that case all the content
of the inline function has to be copied to the place where it is
called. So why should scope of function body still have to be
preserved.

Because the program has to behave as if the function was called.

 

[Alf P. Steinbach /Usenet]

* Suresh V, on 05.07.2010 11:46:

Inline function are compiler optimization in that case all the content
of the inline function has to be copied to the place where it is
called. So why should scope of function body still have to be
preserved.

int main(){
A b;
A a; // Content of createObj;
A c;
return 0;
}

In this case you have a named variable whose lifetime extends to the end of
scope. The lifetime of a temporary extends to the end of the full expression it
occurs in, unless it's bound to a named reference to const whose lifetime
extends to the end of the scope.

Your ideas about inline are partly wrong and partly right and unrelated to the
lifetime rules.

A routine defined in the class definition is indeed 'inline'. This means that it
can be defined, identically, in two or more compilation units, which facilitates
definining it in a header file, so a good way to think of it is that the
defining text is inline. Being inline also serves as a vague hint to the
compiler about inlining the machine code (to the extent that that's practically
possible for this compiler and routine, if it's done). The hint is nothing that
you should rely on, though, and it's not the primary thing. The only sure,
guaranteed behavior resulting from 'inline' is the multiple-definition behavior
-- and it has nothing to do with lifetime.


Cheers & hth.,

- Alf

 

[Suresh V]

* Suresh V, on 05.07.2010 11:46:





In this case you have a named variable whose lifetime extends to the end of
scope. The lifetime of a temporary extends to the end of the full expression it
occurs in, unless it's bound to a named reference to const whose lifetime
extends to the end of the scope.

Your ideas about inline are partly wrong and partly right and unrelated to the
lifetime rules.

A routine defined in the class definition is indeed 'inline'. This means that it
can be defined, identically, in two or more compilation units, which facilitates
definining it in a header file, so a good way to think of it is that the
defining text is inline. Being inline also serves as a vague hint to the
compiler about inlining the machine code (to the extent that that's practically
possible for this compiler and routine, if it's done). The hint is nothing that
you should rely on, though, and it's not the primary thing. The only sure,
guaranteed behavior resulting from 'inline' is the multiple-definition behavior
  --  and it has nothing to do with lifetime.

Cheers & hth.,

- Alf

How do i infer the multiple-definition behaviour of 'inline'. Can i
infer by modifying my code ?. Truely say i am still not able to
differentiate it from non-inline function. Is 'inline' meant only
for runtime reduction ?

 

[Fred Zwarts]

Functions which are defined with in a class are by default inline.


Inline function are compiler optimization in that case all the content
of the inline function has to be copied to the place where it is
called. So why should scope of function body still have to be
preserved.

int main(){
A b;
A a; // Content of createObj;
A c;
return 0;
}

No, it is more like:

int main(){
A b;
{ // Content of createObj;
A a; // Content of createObj;
} // Content of createObj;
A c;
return 0;
}

 

[Alf P. Steinbach /Usenet]

* Suresh V, on 05.07.2010 12:45:

How do i infer the multiple-definition behaviour of 'inline'.

It is defined by the C++ standard.

You can obtain drafts of the standard in PDF format for free.

The latest draft is always available from the committee pages.

Can i
infer by modifying my code ?

In practice yes, you'll get a linker error for a multiply defined routine if
it's not 'inline'. But a guaranteed diagnostic for invalid code, no I don't
think so, since as I recall it's Undefined Behavior (which needs not be
diagnosed). Anyway, to make this concrete, try

<code file "foo.h">
#ifndef FOO_H
#define FOO_H

inline void foo() {}

#endif
</code>


<code file="a.cpp">
#include "foo.h"
</code>


<code file="b.cpp">
#include "foo.h"

int main() {}
</code>


Specify both files [a.cpp] and [b.cpp] to your compiler.

It should compile and link fine, but by removing the word 'inline' you should
(in practice) get a linker error for a multiply defined routine.

. Truely say i am still not able to
differentiate it from non-inline function. Is 'inline' meant only
for runtime reduction ?

No; see the article you're replying to.


Cheers & hth.,

- ALf

 

[Suresh V]

* Suresh V, on 05.07.2010 12:45:

How do i infer the multiple-definition behaviour of 'inline'.

It is defined by the C++ standard.

You can obtain drafts of the standard in PDF format for free.

The latest draft is always available from the committee pages.

Can i
infer by modifying my code ?

In practice yes, you'll get a linker error for a multiply defined routine if
it's not 'inline'. But a guaranteed diagnostic for invalid code, no I don't
think so, since as I recall it's Undefined Behavior (which needs not be
diagnosed). Anyway, to make this concrete, try

<code file "foo.h">
#ifndef FOO_H
#define FOO_H

inline void foo() {}

#endif
</code>

<code file="a.cpp">
#include "foo.h"
</code>

<code file="b.cpp">
#include "foo.h"

int main() {}
</code>

Specify both files [a.cpp] and [b.cpp] to your compiler.

It should compile and link fine, but by removing the word 'inline' you should
(in practice) get a linker error for a multiply defined routine.

. Truely say i am still not able to
differentiate it from non-inline function.  Is 'inline' meant only
for runtime reduction ?

No; see the article you're replying to.

Cheers & hth.,

- ALf

Thanks.

 

[James Kanze]

* Suresh V, on 05.07.2010 11:46:

[...]

Being inline also serves as a vague hint to the compiler about
inlining the machine code (to the extent that that's
practically possible for this compiler and routine, if it's
done).

The hint is far from vague. The standard contains a very clear
expression of the intent of inline, and a compiler which ignores
that intent without reason is defective, at least from a QoI
point of view. (It's often useful to ignore it when debugging,
and most compilers have an option to prevent inlining, for
debugging purposes.)

Of course, this really doesn't change the issue much with
regards to the original poster's question. The compiler may
have any number of more or less valid reasons for not inlining
the function (and of course, most compilers will also inline
functions not declared inline, if appropriate).

The hint is nothing that you should rely on, though, and it's
not the primary thing. The only sure, guaranteed behavior
resulting from 'inline' is the multiple-definition behavior
-- and it has nothing to do with lifetime.

The hint is the primary reason for using inline. It's true that
you can't rely on it. But really, you wouldn't make anything
inline before the profiler said it was necessary. And given the
profiler output before and after making something inline, you
can pretty well determine whether it helped or not (and it's
a lot easier to make something inline than to hand code a lot of
other optimizations).

 

[Alf P. Steinbach /Usenet]

* James Kanze, on 05.07.2010 14:56:

* Suresh V, on 05.07.2010 11:46:
[...]
Being inline also serves as a vague hint to the compiler about
inlining the machine code (to the extent that that's
practically possible for this compiler and routine, if it's
done).

The hint is far from vague. The standard contains a very clear
expression of the intent of inline, and a compiler which ignores
that intent without reason is defective, at least from a QoI
point of view. (It's often useful to ignore it when debugging,
and most compilers have an option to prevent inlining, for
debugging purposes.)

Consider a mostly header-only library such as Boost.

Consider how a compiler would have to treat it in order to inline everything
that's technically 'inline', which for Boost is most everything.

In short, your "without reason" encompasses much more than a cursory reading of
your argument would imply, and makes the argument pretty much moot: 'inline' is
by logical necessity a very very weak hint.

Of course, this really doesn't change the issue much with
regards to the original poster's question. The compiler may
have any number of more or less valid reasons for not inlining
the function (and of course, most compilers will also inline
functions not declared inline, if appropriate).


The hint is the primary reason for using inline.

Sorry, no, that's just bull as a general statement. Again, consider a mostly
header-only library such as Boost. For sure, some folks use 'inline' the way you
indicate, so for them that's primary, but generalizing that is invalid.

It's true that
you can't rely on it. But really, you wouldn't make anything
inline before the profiler said it was necessary.

Oh yes, I would.

Again, consider a mostly header-only library such as Boost.

The reason that most things are inline in Boost is /not/ profiling, it's simply
that for a mostly header-only library the code would break the One Definition
Rule if things were not 'inline' -- it would be invalid code.

And given the
profiler output before and after making something inline, you
can pretty well determine whether it helped or not (and it's
a lot easier to make something inline than to hand code a lot of
other optimizations).

Yeah, but the optimization aspect is the lesser aspect (by a wide margin) of
'inline'. The optimization is not guaranteed behavior, and it's not the reason
why most Boost things are inline. The guaranteed behavior is about the One
Definition Rule.



Cheers,

- Alf

 

[Vladimir Jovic]

On Jul 5, 11:05 am, "Alf P. Steinbach /Usenet" <alf.p.steinbach
[snip]

The hint is nothing that you should rely on, though, and it's
not the primary thing. The only sure, guaranteed behavior
resulting from 'inline' is the multiple-definition behavior
-- and it has nothing to do with lifetime.

The hint is the primary reason for using inline. It's true that
you can't rely on it. But really, you wouldn't make anything
inline before the profiler said it was necessary. And given the
profiler output before and after making something inline, you
can pretty well determine whether it helped or not (and it's
a lot easier to make something inline than to hand code a lot of
other optimizations).

So, what is the criteria for inlining a method (or function)?
If the time spent to call the method is comparable to the time spent in
the method, do you then inline it?

 

[Bart van Ingen Schenau]

Inline function are compiler optimization in that case all the content
of the inline function has to be copied to the place where it is
called. So why should scope of function body still have to be
preserved.

You seem to have the idea that inlining a function is comparable to a
textual substitution of the function call with the function body.
That idea is completely wrong. The textual replacement is done by
macros.

When the compiler inlines a function, it must do so without affecting
the observable behaviour of the program (where execution speed and
code-size do _not_ count as observable behaviour).
This means that you can never tell if a function is inlined or not if
you only look at the output generated by the program.

Bart v Ingen Schenau

 

[James Kanze]

* James Kanze, on 05.07.2010 14:56:

* Suresh V, on 05.07.2010 11:46:

[...]

Being inline also serves as a vague hint to the compiler about
inlining the machine code (to the extent that that's
practically possible for this compiler and routine, if it's
done).

The hint is far from vague. The standard contains a very clear
expression of the intent of inline, and a compiler which ignores
that intent without reason is defective, at least from a QoI
point of view. (It's often useful to ignore it when debugging,
and most compilers have an option to prevent inlining, for
debugging purposes.)

Consider a mostly header-only library such as Boost.

Rather atypical, I think. (And Boost isn't all header-only.)

Consider how a compiler would have to treat it in order to
inline everything that's technically 'inline', which for Boost
is most everything.

I was under the impression that the parts of Boost which are
header only were header only because they were templates, not
because they were inline. Some parts of Boost (e.g.
Boost::bind) probably are mostly inline; those that depend on
a lot of small functions which basically do nothing (except
allow the compiler to choose something based on function
overload resolution). Any good compiler had better inline
those. For the rest, I don't know---the parts I've used
(thread, regex) don't make that much use of inline functions,
except for small forwarding functions.

In short, your "without reason" encompasses much more than
a cursory reading of your argument would imply, and makes the
argument pretty much moot: 'inline' is by logical necessity
a very very weak hint.

The intent is that it be a very, very strong hint. Generally
speaking, to be respected *except* when the compiler is so
advanced that it can systematically do better than the
programmer, or because the programmer has asked for something
unreasonable (e.g. inlining a recursive function).

Sorry, no, that's just bull as a general statement. Again,
consider a mostly header-only library such as Boost. For sure,
some folks use 'inline' the way you indicate, so for them
that's primary, but generalizing that is invalid.

It's the design reason. And a quick glance at one or two Boost
headers (format, thread) suggest that it's the main reason in
Boost as well---at least, the inline functions I see there are
ones that the compiler really should generate inline (since they
will disappear completely once it does). (But one can't make
many global statements about Boost, since it is the work of so
many different people.)

Oh yes, I would.

Again, consider a mostly header-only library such as Boost.

The reason that most things are inline in Boost is /not/
profiling, it's simply that for a mostly header-only library
the code would break the One Definition Rule if things were
not 'inline' -- it would be invalid code.

Except that the "mostly header-only" libraries in Boost are also
mostly templates. And template functions can be multiply
defined without breaking the one definition rule. (Take a look
at boost::format, for example.)

Yeah, but the optimization aspect is the lesser aspect (by
a wide margin) of 'inline'.

That's simply false. Except in a few very special cases, it's
the only reason to use inline.

The optimization is not guaranteed behavior, and it's not the
reason why most Boost things are inline.

Examples, please. It's the obvious justification in the couple
of examples I've looked at. And in cases where optimization
doesn't justify inline, the Boost code I've looked at doesn't
use inline.

The guaranteed behavior is about the One Definition Rule.

The only formally guaranteed behavior, yes. But that's really
a behavior that we tolerate (not desire) in order to facilitate
the specific opimization by the compiler.

 

[James Kanze]

On Jul 5, 11:05 am, "Alf P. Steinbach /Usenet" <alf.p.steinbach

[snip]

The hint is nothing that you should rely on, though, and
it's not the primary thing. The only sure, guaranteed
behavior resulting from 'inline' is the multiple-definition
behavior -- and it has nothing to do with lifetime.

The hint is the primary reason for using inline. It's true
that you can't rely on it. But really, you wouldn't make
anything inline before the profiler said it was necessary.
And given the profiler output before and after making
something inline, you can pretty well determine whether it
helped or not (and it's a lot easier to make something
inline than to hand code a lot of other optimizations).

So, what is the criteria for inlining a method (or function)?
If the time spent to call the method is comparable to the time
spent in the method, do you then inline it?

The program isn't fast enough without inline, and is with
inline. That's really the only criteria. You don't use inline
until the profiler says you should, and you verify that the
performance has improved afterwards.

(In library code, it's sometimes a bit more awkward, since you
don't necessarily have access to client code to profile before
you publish the library. Thus, it's a good guess that most
implementations of std::vector will inline
std::vector:perator[], even without profiling user code, since
they don't have access to all of the user code, and it's
a pretty good guess that there will be applications somewhere
where std::vector:perator[] is used in a critical loop. But
the basic principle remains---the only difference is that the
library author is making an informed guess about what the
profiling output will be.)

 

[Alf P. Steinbach /Usenet]

* James Kanze, on 05.07.2010 19:14:

* James Kanze, on 05.07.2010 14:56:

On Jul 5, 11:05 am, "Alf P. Steinbach /Usenet"<alf.p.steinbach
(e-mail address removed)> wrote:
* Suresh V, on 05.07.2010 11:46:
[...]
Being inline also serves as a vague hint to the compiler about
inlining the machine code (to the extent that that's
practically possible for this compiler and routine, if it's
done).
The hint is far from vague. The standard contains a very clear
expression of the intent of inline, and a compiler which ignores
that intent without reason is defective, at least from a QoI
point of view. (It's often useful to ignore it when debugging,
and most compilers have an option to prevent inlining, for
debugging purposes.)

Consider a mostly header-only library such as Boost.

Rather atypical, I think. (And Boost isn't all header-only.)

I wrote "mostly header-only", not "all header-only".

I was under the impression that the parts of Boost which are
header only were header only because they were templates, not
because they were inline.

Nobody's said that those parts (most of Boost) are header-only because they're
inline.

They're inline because they're header-only.

Some of them are templates, some of them are inline functions and classes, and
they're mostly inline /by design/.

Some parts of Boost (e.g.
Boost::bind) probably are mostly inline; those that depend on
a lot of small functions which basically do nothing (except
allow the compiler to choose something based on function
overload resolution). Any good compiler had better inline
those. For the rest, I don't know---the parts I've used
(thread, regex) don't make that much use of inline functions,
except for small forwarding functions.

I don't believe that you have only used the few sub-libraries that require
separate compilation.

I believe that for most people it's opposite.

The intent is that it be a very, very strong hint. Generally
speaking, to be respected *except* when the compiler is so
advanced that it can systematically do better than the
programmer, or because the programmer has asked for something
unreasonable (e.g. inlining a recursive function).

No matter whether it is the exceptions that make it so, or whatever, it is by
logical necessity a very very weak hint.

That's why compilers in general have additional means to specify that you really
want machine code inlining.

It just isn't covered by the language's "inline" in the context of modern
programming (it was different in the eighties, yes, e.g. if you look at Bjarne's
writings at that time).

It's the design reason. And a quick glance at one or two Boost
headers (format, thread) suggest that it's the main reason in
Boost as well---at least, the inline functions I see there are
ones that the compiler really should generate inline (since they
will disappear completely once it does). (But one can't make
many global statements about Boost, since it is the work of so
many different people.)

Picking and choosing atypical examples is an invalid way of selecting examples;
if those are the only things that you have checked out in Boost then I suggest
doing a more complete survey of What's There.

You can rely on the Boost documentation when it states, <url:
http://www.boost.org/doc/libs/1_43_0/more/getting_started/windows.html#header-only-libraries>,
that an advantage of Boost is that most things are inline:

<Boost-docs>
Most Boost libraries are header-only: they consist entirely of header files
containing templates and inline functions, and require no separately-compiled
library binaries or special treatment when linking.
</Boost-docs>

I'm quoting that mostly just for the benefit of other readers, because I
strongly suspect that you knew that already and argued otherwise in spite of
knowing your arguments to be incorrect.


[snip]

The only formally guaranteed behavior, yes. But that's really
a behavior that we tolerate (not desire) in order to facilitate
the specific opimization by the compiler.

Uhm, your work environment must be pretty atypical.



Cheers & hth.,

- Alf

 

[Ian Collins]

* Suresh V, on 05.07.2010 11:46:
[...]
Being inline also serves as a vague hint to the compiler about
inlining the machine code (to the extent that that's
practically possible for this compiler and routine, if it's
done).

The hint is far from vague. The standard contains a very clear
expression of the intent of inline, and a compiler which ignores
that intent without reason is defective, at least from a QoI
point of view. (It's often useful to ignore it when debugging,
and most compilers have an option to prevent inlining, for
debugging purposes.)

Of course, this really doesn't change the issue much with
regards to the original poster's question. The compiler may
have any number of more or less valid reasons for not inlining
the function (and of course, most compilers will also inline
functions not declared inline, if appropriate).

The hint is nothing that you should rely on, though, and it's
not the primary thing. The only sure, guaranteed behavior
resulting from 'inline' is the multiple-definition behavior
-- and it has nothing to do with lifetime.

The hint is the primary reason for using inline.

Surly the multiple-definition behaviour is the primary reason for using
inline?

The hint is just that, a hint. Odds are the same functions will be
unlined whether the inline keyword is present or not.

It's true that
you can't rely on it. But really, you wouldn't make anything
inline before the profiler said it was necessary. And given the
profiler output before and after making something inline, you
can pretty well determine whether it helped or not (and it's
a lot easier to make something inline than to hand code a lot of
other optimizations).

The only way for force inline is is to use any pragmas provided by the
compiler to override its inline selection heuristics. The only entity
that can really make use of profiler output in determining inline
selection is the compiler its self though profile feedback optimisations.

If you do go down the manual inline route, you will have to profile on
every processor variant you wish to deploy your application. Not just
every architecture, but every processor variant. This is really only
practical on embedded platforms, one reason embedded compilers provide
the necessary support (pragmas). Another reason for manual intervention
is profile feedback is normally impractical on embedded platforms.

 

[James Kanze]

* James Kanze, on 05.07.2010 19:14:

[...]

Nobody's said that those parts (most of Boost) are header-only
because they're inline.

They're inline because they're header-only.

Except that the parts I looked at aren't inline, even when
they're header only.

Some of them are templates, some of them are inline functions
and classes, and they're mostly inline /by design/.

Most of the header only libraries are templates. I've not seen
that many inline functions in them; only for very trivial
things, where performance is clearly an issue, or for cases
where the function doesn't actually do anything except forward
to another function (and where it should disappear from the
generated code if it is inlined).

I've posted the examples I've seen that don't use inline
functions. Maybe you could mention one or two that use inline
functions in order to make the library header-only. I can't
find one.

I don't believe that you have only used the few sub-libraries
that require separate compilation.

No, but the others don't have that many inline functions either.

I believe that for most people it's opposite.

No matter whether it is the exceptions that make it so, or
whatever, it is by logical necessity a very very weak hint.

That's why compilers in general have additional means to
specify that you really want machine code inlining.

Which compilers? The standard specifies a specific mechanism;
it's rather irresponsible for the compiler to decide to use
another one.

It just isn't covered by the language's "inline" in the
context of modern programming (it was different in the
eighties, yes, e.g. if you look at Bjarne's writings at that
time).

Except that the issues concerning inline haven't changed since
then. The definition is the same as it was then (except that
the standard makes it clear that inline doesn't change semantics
or linkage---the original version of inline make the function
implicitly static).

[...]

Picking and choosing atypical examples is an invalid way of
selecting examples; if those are the only things that you have
checked out in Boost then I suggest doing a more complete
survey of What's There.

So what are you're typical examples?

You can rely on the Boost documentation when it states, <url:http://www.boost.org/doc/libs/1_43_0/more/getting_started/windows.htm...>,
that an advantage of Boost is that most things are inline:

<Boost-docs>
Most Boost libraries are header-only: they consist entirely
of header files containing templates and inline functions,
and require no separately-compiled library binaries or
special treatment when linking.
</Boost-docs>

I'm quoting that mostly just for the benefit of other readers,
because I strongly suspect that you knew that already and
argued otherwise in spite of knowing your arguments to be
incorrect.

I'd never seen it before, but it sounds rather vague. Most of
the Boost libraries make extensive use of templates. You don't
need inline to make them header-only. The fact that they're
header only is a side-effect of the fact they use templates (and
a negative side effect at that---header-only is a distinct
disadvantage).

[snip]

The only formally guaranteed behavior, yes. But that's really
a behavior that we tolerate (not desire) in order to facilitate
the specific opimization by the compiler.

Uhm, your work environment must be pretty atypical.

It's spanned a fairly large number of application domains.

 

[James Kanze]

* Suresh V, on 05.07.2010 11:46:

[...]

Being inline also serves as a vague hint to the compiler
about inlining the machine code (to the extent that that's
practically possible for this compiler and routine, if it's
done).

The hint is far from vague. The standard contains a very
clear expression of the intent of inline, and a compiler
which ignores that intent without reason is defective, at
least from a QoI point of view. (It's often useful to
ignore it when debugging, and most compilers have an option
to prevent inlining, for debugging purposes.)
Of course, this really doesn't change the issue much with
regards to the original poster's question. The compiler may
have any number of more or less valid reasons for not
inlining the function (and of course, most compilers will
also inline functions not declared inline, if appropriate).

The hint is nothing that you should rely on, though, and
it's not the primary thing. The only sure, guaranteed
behavior resulting from 'inline' is the multiple-definition
behavior -- and it has nothing to do with lifetime.

The hint is the primary reason for using inline.

Surly the multiple-definition behaviour is the primary reason
for using inline?

Actually, it's the primary reason for avoiding it. In a typical
development environment, the multiple-definition behavior
replaces a link-time error with truly undefined (and somewhat
random) behavior. Not something particularly desirable. The
fact that the code has to be in the header increases coupling.
Significantly if the function is non-trivial. The only
justification for having inline at all is performance.

The hint is just that, a hint. Odds are the same functions
will be unlined whether the inline keyword is present or not.

And that some will be inlined even if the inline keyword is not
present. That's why the use has to be profiler driven.

The only way for force inline is is to use any pragmas
provided by the compiler to override its inline selection
heuristics.

And how is that relevant? You are trying to optimize code.
Depending on the compiler, different techniques may or may not
be appropriate. Inline is a useful technique: it has the
advantage that it is very, very easy to use, and that it is
guaranteed to compile with the same semantics everywhere---you
don't need #ifndef's or whatever to use it. (Although you
might, if e.g. it results in the code running slower on some
other compiler.) If it works (i.e. the results become "fast
enough"), you win. If it doesn't, you haven't lost too much
time exploring a dead-end alley.

The only entity that can really make use of profiler output in
determining inline selection is the compiler itself though
profile feedback optimisations.

That's the ideal situation, and such compilers typically will
ignore the hint. Once such compilers become common place,
I imagine that inline will go the way of register. But we're
not there yet.

If you do go down the manual inline route, you will have to
profile on every processor variant you wish to deploy your
application.

Possibly. That's often the case when your code isn't fast
enough. (Of course, it may be just one platform on which it
isn't fast enough. In that case, that's the only one you have
to profile.)