How to make inline work?

[Barry]

Hi, group

First, I write same cases I've already known, I don't concern that
specific compiler really do inline or not.
Please check them if they are right, and add the cases I miss

1.
// a.h
inline void f() {}

*inline*

2.
//a.h
inline void f();
//a.cpp
#include "a.h"
void f() {}

*NOT* inline, compiler just ignores the keyword

3.
// a.h
class A {
void f1() {}
inline void f2() {}
};

*inline*

4.
// a.h
class A {
inline void f2();
};

//a.cpp
#include "a.h"

void A::f() {}

*not* inline


5.
// a.h
class A {
void f();
};

//a.cpp
#include "a.h"

inline
void A::f() {}

*not* inline

6.
// a.h
class A {
void f();
};

inline void A::f() {}

*inline*

7.
//a.h
template <typename T>
class A {
void f1();
void f2() {}
};

template <typename T>
void A::f1() {}

*inline*

After so many examples,
I sum up from my humble experience, *inline* works comes with the
function definition not the declaration. Is there any exception?

Like
// a.h
class A {
inline void f();
};

void A::f() {}

*inline?*

thanks

 

[Barry]

Hi, group

First, I write same cases I've already known, I don't concern that
specific compiler really do inline or not.
Please check them if they are right, and add the cases I miss

1.
// a.h
inline void f() {}

*inline*

2.
//a.h
inline void f();
//a.cpp
#include "a.h"
void f() {}

*NOT* inline, compiler just ignores the keyword

3.
// a.h
class A {
void f1() {}
inline void f2() {}
};

*inline*

4.
// a.h
class A {
inline void f2();
};

//a.cpp
#include "a.h"

void A::f() {}

*not* inline


5.
// a.h
class A {
void f();
};

//a.cpp
#include "a.h"

inline
void A::f() {}

*not* inline

6.
// a.h
class A {
void f();
};

inline void A::f() {}

*inline*

7.
//a.h
template <typename T>
class A {
void f1();
void f2() {}
};

template <typename T>
void A::f1() {}

*inline*

After so many examples,
I sum up from my humble experience, *inline* works comes with the
function definition not the declaration. Is there any exception?

Like
// a.h
class A {
inline void f();
};

void A::f() {}

*inline?*

*wrong* if included by more than one translation unit violate the one
time definition rule

so *NOT* inline, even *wrong*

 

[Bo Persson]

Barry wrote:
:: Barry wrote:
::: Hi, group
:::
:::
::: After so many examples,
::: I sum up from my humble experience, *inline* works comes with the
::: function definition not the declaration. Is there any exception?
:::
::: Like
::: // a.h
::: class A {
::: inline void f();
::: };
:::
::: void A::f() {}
:::
::: *inline?*
::
:: *wrong* if included by more than one translation unit violate the
:: one time definition rule
::
:: so *NOT* inline, even *wrong*

Well, wrong but may be inlined anyway.

Actually this is the *only* real use for the inline keyword - to avoid
breaking the ODR. All the others are up to the compiler.

With the compiler I use, inlining is selectable by compiler options:
- don't inline anything
- inline only functions marked 'inline'
- inline anything that seems worthwhile

With the last option, the compiler ignores 'inline' except for ODR. It
also inlines functions across compilation units (your case #2, #4 and
#5).


Bo Persson

 

[James Kanze]

[...]

Actually this is the *only* real use for the inline keyword -
to avoid breaking the ODR. All the others are up to the
compiler.

There's also very explicit text in the standard that it should
be used as an optimization hint. From a quality of
implementation point of view, a compiler which ignores inline
for this reason had better be able to do a better job at
deciding that the programmer. (There are a few, but it's not
the usual situation.)

With the compiler I use, inlining is selectable by compiler options:
- don't inline anything
- inline only functions marked 'inline'
- inline anything that seems worthwhile

With the last option, the compiler ignores 'inline' except for
ODR. It also inlines functions across compilation units (your
case #2, #4 and #5).

Using the profiler output, I presume, to decide which functions
need inlining.

 

[Bo Persson]

James Kanze wrote:
:
: [...]
:: Actually this is the *only* real use for the inline keyword -
:: to avoid breaking the ODR. All the others are up to the
:: compiler.
:
: There's also very explicit text in the standard that it should
: be used as an optimization hint. From a quality of
: implementation point of view, a compiler which ignores inline
: for this reason had better be able to do a better job at
: deciding that the programmer. (There are a few, but it's not
: the usual situation.)

This is MSVC (>> v6), which often does a good job at this. It is also
configurable, like I say below. Option 2 will make it honor the
programmers choice. Option 3 most often results in faster code (if
that is what you want).

:
:: With the compiler I use, inlining is selectable by compiler
:: options:
:: - don't inline anything
:: - inline only functions marked 'inline'
:: - inline anything that seems worthwhile
:
:: With the last option, the compiler ignores 'inline' except for
:: ODR. It also inlines functions across compilation units (your
:: case #2, #4 and #5).
:
: Using the profiler output, I presume, to decide which functions
: need inlining.

If available, yes. Otherwise it uses its usual heuristics - small
enough function, not more than x levels of inline expansion (where x
is also configurable).

My point was rather that having the function in a .cpp file does not
stop the compiler from inlining it. You have to set the right options
to get what you want.



Bo Persson

 

[James Kanze]

James Kanze wrote:

:
: [...]
:: Actually this is the *only* real use for the inline keyword -
:: to avoid breaking the ODR. All the others are up to the
:: compiler.

: There's also very explicit text in the standard that it should
: be used as an optimization hint. From a quality of
: implementation point of view, a compiler which ignores inline
: for this reason had better be able to do a better job at
: deciding that the programmer. (There are a few, but it's not
: the usual situation.)

This is MSVC (>> v6), which often does a good job at this. It is also
configurable, like I say below. Option 2 will make it honor the
programmers choice. Option 3 most often results in faster code (if
that is what you want).

Presumably, if you didn't have a performance problem, you
wouldn't be considering inline to begin with. Other than
possibly improved performance (which, of course, you would
verify), it has only disadvantages.

[...]

My point was rather that having the function in a .cpp file does not
stop the compiler from inlining it. You have to set the right options
to get what you want.

Certainly. For a given compiler. My only real point was the
statement "Actually this is the *only* real use for the inline
keyword - to avoid breaking the ODR. All the others are up to
the compiler." The only real use for the inline keyword is that
the profiler said something was necessary, and then showed that
inline did what was necessary. If your compiler does better, so
much the better, but it's not always the case.