«

Hi,
- Are there any cardinal rules as to when a function should not be
inlined?

- If a function, say f, is being called from multiple other
functions/classes, should that function f, be always inlined?

- Does the C++ standard talk about this? What about gcc 3.x
implementation?

- Any resources/pointers would be great help.


Thanks
.....Abhi

"Abhi" <> wrote in message
news: om...
> Hi,
> - Are there any cardinal rules as to when a function should not be
> inlined?

I don't think so. Inlining closely couples the interface and the
implementation. Sometimes that's just what you want:

class Complex // I'm too dumb to use std::complex<double>
{
private:
double m_re, m_im;
public:
Complex(double i_re, i_im) : m_re(i_re), m_im(i_im) {}
double re() const {return m_re;}
double im() const {return m_im;}
};

Here the functions re() and im() give read-only access to the internal
representation of the class. There is no pretense that the real and
imaginary parts are ever going to be implemented as anything but a pair of
doubles. Also, the inlining may improve the performance, and in a concrete
data type like this I don't really need to see profiling data to justify
it -- as far as I am concerned this type of inspector function is just part
of the concrete data type paradigm.

But:

class SomeClass
{
public:
void some_func() {...200 lines of code here...}
};

would almost certainly be a mistake. If the compiler inlines the code (and
after all, you DID ask it to) every call will use a lot of memory and the
function call overhead you saved would be negligible.

>
> - If a function, say f, is being called from multiple other
> functions/classes, should that function f, be always inlined?

The more places it is called from the more I would be inclined to avoid
inlining. In principle each call to an inline function creates another copy
of the object code. The thing that suggests inlining is a calling sequence
like:

for (int j = 0; j < 10000; ++j)
sum += obj.f();

If f() is doing something very simple (like just indexing a pointer) the
function call overhead might be a little high. Even then though it is
probably not a big deal.

>
> - Does the C++ standard talk about this? What about gcc 3.x
> implementation?

The standard only says what it is. Dunno about gcc.

>
> - Any resources/pointers would be great help.
>
>
> Thanks
> ....Abhi

Abhi wrote:

> - Are there any cardinal rules
> as to when a function should not be inlined?
>
> - If a function, say f, is being called
> from multiple other functions/classes,
> should that function f, be always inlined?
>
> - Does the C++ standard talk about this?
> What about gcc 3.x implementation?
>
> - Any resources/pointers would be great help.

The purpose of inline functions is to discourage
manual inlining of functions by programmers
who are concerned about performance.

Programs are easier the read, understand and maintain
if they are decomposed into re-usable functions.
If the function definitions are visible to the compiler
it can *inline* these functions automatically
to eliminate the extra overhead of a function call
and to permit optimizations that are frustrated
by external function definitions.

The problem with inline functions is that
they must be parsed every time you recompile your program
during program development.
The solution is to define both inline and external version
of your function:

> cat file.h
#ifndef GUARD_FILE_H
#define GUARD_FILE_H 1

#ifdef EFINE_INLINE
inline
double dot(const double x[], const double y[], int n) {
double t = 0.0;
for (int j = 0; j < n; ++j)
t += x[j]*y[j];
return t;
}
#else //EFINE_INLINE
double dot(const double x[], const double y[], int n);
#endif//EFINE_INLINE
#endif//GUARD_FILE_H

> cat file.cc
#undef EFINE_INLINE
#include <file.h>

double dot(const double x[], const double y[], int n) {
double t = 0.0;
for (int j = 0; j < n; ++j)
t += x[j]*y[j];
return t;
}

Application programs quickly compile and link
with the external version of the function
during program development, testing and debugging
then are recompiled with C preprocessor option

-DEFINE_INLINE

just before deployment. This final compilation may be much slower
but the result is code which runs much faster.