TITLE: Rationale for using inlined methods


PROBLEM: handsaw@nando.net

I was looking at some code today that had an inline function that had a
for loop in it and the compiler gave a warning that it didn't do inline
functions with for loops in them.

So, I took out the inline from in front of the function and the linker gave
errors that the function was defined in multiple places. 


RESPONSE: clamage@Eng.Sun.COM (Steve Clamage), 4 Apr 95

"inline" is a request to the compiler that it generate inline code instead
of a function call. Except for class member functions, it is equivalent
to declaring the function "static". If the compiler chooses, for whatever
reason, not to generate the function inline, it will generate an ordinary
static function in each module where the inline is used. 

In order to get a function generated inline, the compiler must see a
definition of the function (its body) before the function is called in a
module. This generally means that the inline function gets put into a
header file and included in more than one of the modules that make up the
program. If you remove the word "inline" from the function definition
in the header file, it becomes a global function, not a static function,
and you are not allowed to provide more than one definition (body) for
the function in the entire program. (Hence, the "multiple definition" error.)

Your choices are basically these:
1. Ignore the warning about inline.
2. Change "inline" to "static", which will mean you will never get an inline
   version, even when ported to a compiler which might otherwise inline it,
   and you will always have multiple copies of the function.
3. Put only a prototype for the function in the header, and define it as an
   ordinary global function in one file. This means it will never be inline,
   but you will never have more than one copy of the function in the program.

The consequences of #1 depend on the compiler. I believe the Borland compiler
and linker cooperate to squeeze out extra copies of inline functions which
were generated as ordinary functions. This gives you the best results.
You can probably disable the warning about not generating inline functions
while leaving other warnings intact.

Finally, it may not make sense to declare the function inline at all. The
reasons for making a function inline are to avoid the overhead of the
call and return sequence, and perhaps create additional opportunities for
optimization by combining the function body with surrounding code.

A function which does a significant amount of work probably will not
benefit the program if it is generated inline. It increases code size if
called more than once, and the overhead of the call/return may not make
a measurable difference. Careless use of inline can result in programs
which are both larger and slower than they would otherwise be, since the
larger program can increase the working set size and/or cause cache failures.

I use this rule of thumb: A function is a candidate for inline generation
if the calling sequence (the code it takes to set up the call and return)
is comparable in size or speed to that of the body of the function. If
the body of the function is significantly larger and slower than the
calling sequence, the function should probably not be made inline.