inline functions

I haven't found any previous message related to what I'm going to ask here,
but accept my anticipated excuses if I'm wrong.

I want to ask about the real usefulness of the 'inline' keyword. I've read
many authors (and it's my belief, too) who discourage the use of the
'inline' keyword, because:

- The 'inline' word only advice the compiler about wich functions should be
expanded, but not force it to expand them. Also, the compiler can decide to
expand a function not declared as 'inline' by the programmer. So, in last
instance, 'inline' function expansion it's completely guided by compiler's
decisions, not by programmer's ones.

- It is required to include 'inline' function definitions in the
corresponding header file, with the consequences (recompilation of all
source file including the target header file) that a change in them implies,
specially in big projects.

I'm sure about this, and I not use the 'inline' keyword. But recently I've
seen opposed examples in some libraries' header files, "boost" between them.
This fact have induced me to ask myself another time about this matter.
Thank you :-)

"Rubén Campos" <Ruben.Campos@robotica.uv.es> wrote in message
news:cibomk$v53$1@peque.uv.es...
> I haven't found any previous message related to what I'm going to ask
here,
> but accept my anticipated excuses if I'm wrong.
>
> I want to ask about the real usefulness of the 'inline' keyword. I've read
> many authors (and it's my belief, too) who discourage the use of the
> 'inline' keyword, because:
>
>  - The 'inline' word only advice the compiler about wich functions should
be
> expanded, but not force it to expand them. Also, the compiler can decide
to
> expand a function not declared as 'inline' by the programmer. So, in last
> instance, 'inline' function expansion it's completely guided by compiler's
> decisions, not by programmer's ones.

Not true. The compiler cannot inline a function that is in a different
translation unit (assuming it does seperate compilation, which AFAIK they
all do). So if you want to give the compiler the *opportunity* to inline a
function in more than one translation unit it must go in a header file, and
therefore it must be declared inline.

>
>  - It is required to include 'inline' function definitions in the
> corresponding header file, with the consequences (recompilation of all
> source file including the target header file) that a change in them
implies,
> specially in big projects.
>

True enough, but you pay your money and you take your choice.

> I'm sure about this, and I not use the 'inline' keyword. But recently I've
> seen opposed examples in some libraries' header files, "boost" between
them.
> This fact have induced me to ask myself another time about this matter.
> Thank you :-)
>

john

Rubén Campos wrote:

> I haven't found any previous message related to what I'm going to ask here
,
> but accept my anticipated excuses if I'm wrong.
>
> I want to ask about the real usefulness of the 'inline' keyword. I've read
> many authors (and it's my belief, too) who discourage the use of the
> 'inline' keyword, because:


Not true. Inline is a useful feature for run-time optimisation, when
used appropriately.


Take a look at:  http://www.research.att.com/~bs/esc99.html




>  - The 'inline' word only advice the compiler about wich functions should 
be
> expanded, but not force it to expand them. Also, the compiler can decide t
o
> expand a function not declared as 'inline' by the programmer. So, in last
> instance, 'inline' function expansion it's completely guided by compiler's
> decisions, not by programmer's ones.


However programmers may take more wise inlining decisions than the compiler.


Also in most cases the compiler listens to the programmer inlining requests.



>  - It is required to include 'inline' function definitions in the
> corresponding header file, with the consequences (recompilation of all
> source file including the target header file) that a change in them implie
s,
> specially in big projects.


Inline should be used for small definitions, and in most such cases
rarely the definition is changed slightly. Also if you want to avoid
that, then do not inline.


If you want the code to be inlined so as to avoid redundant function
calls, while at the same time the produced binary will not get increased
significantly if the specific function or member function is inlined,
then use inline.

There are not perfect solutions that resolve all problems, but the
decisions are up to the programmer to take.



> I'm sure about this, and I not use the 'inline' keyword. But recently I've
> seen opposed examples in some libraries' header files, "boost" between the
m.
> This fact have induced me to ask myself another time about this matter.
> Thank you :-)


Of course. Inline is widely used and yields significant benefits when
used appropriately.



--
Ioannis Vranos

http://www23.brinkster.com/noicys

Rubén Campos wrote:

> I want to ask about the real usefulness of the 'inline' keyword.

I think that you just did.

> I've read many authors (and it's my belief, too)
> who discourage the use of the 'inline' keyword, because:
>
>  - The 'inline' word only advice the compiler
> about which functions should be expanded,
> but [does] not force it to expand them.
> Also, the compiler can decide to expand a function
> not declared as 'inline' by the programmer.
> So, in last instance, 'inline' function expansion
> [is] completely guided by compiler's decisions,
> not by [the] programmer's [decisions].

No, not quite.
The compiler can't expand a function inline
if the function definition is not visible to the compiler --
if the function definition is in a different translation unit
for example.

>  - 'inline' function definitions must be included
> in the corresponding header file,
> with the consequences that a change in them implies
> (recompilation of all source file including the target header file)
> especially in big projects.

Yes.  In general, you pay a penalty at compile time for optimizations
that enhance performance at run time.

> I'm sure about this, and I [do] not use the 'inline' keyword.
> But, recently, I've seen opposed examples in some libraries' header files
> "boost" [among] them.
> This fact has induced me to ask myself another time about this matter.

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:

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

Well, first of all thank you, John, Ioannis and Robert, for your answers.
You're right when you talk about the need of having inline function
declaration and definition both in the same translation unit.

Related to the code model proposed by Robert, I think the next model I found
in the book "Industrial C++" is better:

// MyClass.h
...
class MyClass
{
void MyInlineMethod ();
};
...
#ifdef ENABLE_INLINE
#include "MyClass.inl"
#endif // #ifdef ENABLE_INLINE

// MyClass.cpp
#include "MyClass.h"
...
#ifndef ENABLE_INLINE
#include "MyClass.inl"
#endif // #ifndef ENABLE_INLINE

// MyClass.inl
#ifndef ENABLE_INLINE
#define inline
#endif // #ifndef ENABLE_INLINE
...
inline void MyClass::MyInlineMethod ()
{
cout << "This is an inline member function" << endl;
}
...
#ifndef ENABLE_INLINE
#undef inline
#endif // #ifndef ENABLE_INLINE

Again, inlining can be enabled or disabled by defining or not defining
ENABLE_INLINE macro. The reasons for which I think it's better are:

- MyClass header file does not include any function implementation.
- Inline function implementation does not need to be duplicated.

The only problem I see with this is the definition of a language keyword
("#define inline"). Perhaps it can be avoided by replacing 'inline' with a
custom 'INLINE' macro, defined as 'inline' or as empty, depending if the
ENABLE_INLINE is defined.

Rubén Campos wrote:

> Well, first of all thank you, John, Ioannis and Robert, for your answers.
> You're right when you talk about the need of having inline function
> declaration and definition both in the same translation unit.
>
> Related to the code model proposed by Robert, I think the next model I fou
nd
> in the book "Industrial C++" is better:
>
> // MyClass.h
> ...
> class MyClass
> {
>     void MyInlineMethod ();
> };
> ...
> #ifdef ENABLE_INLINE
> #include "MyClass.inl"
> #endif // #ifdef ENABLE_INLINE
>
> // MyClass.cpp
> #include "MyClass.h"
> ...
> #ifndef ENABLE_INLINE
> #include "MyClass.inl"
> #endif // #ifndef ENABLE_INLINE
>
> // MyClass.inl
> #ifndef ENABLE_INLINE
> #define inline
> #endif // #ifndef ENABLE_INLINE
> ...
> inline void MyClass::MyInlineMethod ()
> {
>     cout << "This is an inline member function" << endl;
> }
> ...
> #ifndef ENABLE_INLINE
> #undef inline
> #endif // #ifndef ENABLE_INLINE
>
> Again, inlining can be enabled or disabled by defining or not defining
> ENABLE_INLINE macro. The reasons for which I think it's better are:
>
>  - MyClass header file does not include any function implementation.
>  - Inline function implementation does not need to be duplicated.
>
> The only problem I see with this is the definition of a language keyword
> ("#define inline"). Perhaps it can be avoided by replacing 'inline' with a
> custom 'INLINE' macro, defined as 'inline' or as empty, depending if the
> ENABLE_INLINE is defined.



Avoid macros as much as possible. In all decent compilers, if you need
to disable inlining of inline functions and member functions, the
compiler provides a special compiler switch.



--
Ioannis Vranos

http://www23.brinkster.com/noicys

Ioannis Vranos wrote:

> Avoid macros as much as possible.
> In all decent compilers, if you need to disable inlining
> of inline functions and member functions,
> the compiler provides a special compiler switch.

You missed the point.
We don't want to disable inlining.
We want to prevent the compiler
from processing the inline function definitions
because it takes time and slows down development cycles.
We use the C preprocessor
to remove the inline function definitions and substitute
external function declarations in the translation unit
so that the program will compile and link faster.

E. Robert Tisdale wrote:

> You missed the point.
> We don't want to disable inlining.
> We want to prevent the compiler
> from processing the inline function definitions
> because it takes time and slows down development cycles.
> We use the C preprocessor
> to remove the inline function definitions and substitute
> external function declarations in the translation unit
> so that the program will compile and link faster.


I have not much development history, but don't all modern compilers
support incremental compilation, so as to not recompile anything that
has already been compiled?



--
Ioannis Vranos

http://www23.brinkster.com/noicys

"E. Robert Tisdale" <E.Robert.Tisdale@jpl.nasa.gov> wrote in message news:<c
ichuk$q6d$1@nntp1.jpl.nasa.gov>...

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

That's a dangerous statement, Bob. One has to use 'inline' functions
as judiciously as one can. 'inline'-ing is not evil, but used without
enough thought or judgment, it can soon be the next worst thing for
your program's performance in time and space.

Scott Meyers writes an amazing item on this issue in Effective C++.

For one, all calls to an inlined function will be replaced by the
function's object code - object code replication - potentially leading
to code bloat.

Second, and this is very important, you got to consider the behaviour
of your compiler when "inline" requests cannot be satisfied. How the
compiler handles "outlined" inlines determines whether your code
suffers any code-bloat.

Never inline virtual functions because they would hardly ever be
inlined. How can the compiler know which function to inline when it
does not know at compile time which function to call.

Also, using inline calls with debuggers is trouble-some. I guess,
inlining should only be considered at the time of optimized builds,
not the initial builds anyway.

Modern day compilers are smart enough to ignore almost any inlining
request that doesn't beggar a lookin for itself. Only the simplest and
shortest functions manage to convince the compiler to inline them ...
and that too needs the inline directive or being defined within the
body of the class.

Cheers,
Andy

Andy wrote:

> E. Robert Tisdale wrote:
> 
>
> That's a dangerous statement.
> One [must] use 'inline' functions as judiciously as one can.
> 'inline'-ing is not evil but, used without enough thought or judgment,
> it can soon be the next worst thing
> for your program's performance in time and space.
>
> Scott Meyers writes an amazing item on this issue in Effective C++.
>
> For one, all calls to an inlined function will be replaced
> by the function's object code - object code replication -
> potentially leading to code bloat.

The typical application here at the Lab is about 2 MBytes.
The typical processing node has 2 GBytes memory --
the application code absorbs about 0.1% of that.
I can get disk space for about $0.50 per GByte at Fry's
which means that it costs me about 0.1 cents to keep a "bloated"
application program on my hard drive.
Code bloat is *not* a problem -- for me or most other C++ programmers.

> Second, and this is very important,
> you [must] consider the behavior of your compiler
> when "inline" requests cannot be satisfied.
> How the compiler handles "outlined" inlines
> determines whether your code suffers any code-bloat.

> Never inline virtual functions
> because they would hardly ever be inlined.
> How can the compiler know which function to inline
> when it does not know at compile time which function to call.

> Also, using inline calls with debuggers is trouble-some.
> I guess, inlining should only be considered
> at the time of optimized builds,
> not the initial builds anyway.

> Modern day compilers are smart enough
> to ignore almost any inlining request
> that doesn't beggar a lookin for itself.
> Only the simplest and shortest functions
> manage to convince the compiler to inline them ...

Unfortunately, most C++ programmer are *not* that smart.
They will *manually* inline scores of simple functions
until they have a few complicated functions
with hundreds of lines of code in each one.

> and that too needs the inline directive
> or being defined within the body of the class.

The purpose of inline functions
is to encourage programmers to decompose their functions
into smaller functions and allow the compiler
to inline them *automatically*.
The result should be programs that are
easier to read, understand and maintain
without sacrificing performance or efficiency.
But this isn't possible for most C++ compilers
is you stuff the the functions into a separate translation unit
where the compiler can't see them.

I'm guessing from your remarks that
you write big fat functions
where you have manually inlined the same functions repeatedly
so that they are bloated by by design.

The point is that inline functions are *not* really about
performance, efficiency or code bloat.
They are about encouraging good programming practice.
The eliminate all of the excuses for manual inlining
and large complicated functions.