To inline or not to inline?

[Alvin]

Hello all,

I'm curious as to your opinions on explicitly inlining function? I'm talking
about functions as members of a class. For example, so class A defines a
operator==() and a operator!=():

class_a.h:

class A
{
public:
A();
bool operator==(A &rhs);
inline bool operator!=(A &rhs);
...
};

bool A::operator!=(A &rhs)
{
return !(*this == rhs);
}

Is it something that should be done by the programmer or should we assume
that compiler optimisations will take care of it?

--
Alvin

[Alf P. Steinbach]

* Alvin:

I'm curious as to your opinions on explicitly inlining function? I'm talking
about functions as members of a class. For example, so class A defines a
operator==() and a operator!=():

class_a.h:

class A
{
public:
A();
bool operator==(A &rhs);
inline bool operator!=(A &rhs);
...
};

bool A::operator!=(A &rhs)
{
return !(*this == rhs);
}

Is it something that should be done by the programmer or should we assume
that compiler optimisations will take care of it?

The keyword 'inline' is not primarily about optimization.

See section 3 of chapter 2.1 (i.e. section 2.1.3) of my attempted correct
C++ tutorial at

<url: http://home.no.net/dubjai/win32cpptut/html/w32cpptut_02.html>

and also the FAQ at

<url: http://www.parashift.com/c++-faq-lite/inline-functions.html>

(The tutorial refers to the FAQ, and the FAQ refers to the tutorial, so if
you like to go in circles you can follow the links... ;-) )

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Thomas Matthews]

Alvin wrote:

Hello all,

I'm curious as to your opinions on explicitly inlining function? I'm talking
about functions as members of a class. For example, so class A defines a
operator==() and a operator!=():

class_a.h:

class A
{
public:
A();
bool operator==(A &rhs);
inline bool operator!=(A &rhs);
...
};

bool A::operator!=(A &rhs)
{
return !(*this == rhs);
}

Is it something that should be done by the programmer or should we assume
that compiler optimisations will take care of it?

In my opinion, functions and methods should be inlined
when the execution cost of their content is less than
or equal to the function call & return overhead; provided
the function has already been tested as a non-inlined
function.

Exceptions:
1. Development.
Many compilers have problems providing debugging
information for inlined functions.

2. Deliverable headers.
Interfaces for the external customer, such as
libraries, should not have inlined functions;
or change the design so that the delivered headers
do not contain inlined code.

Again, this is my opinion. Yours may differ.

Remember that the keyword "inline" is only a suggestion
to the compiler. The compiler may already be inlining
the function (or eliminating it).

Don't worry about optimizations until the project
works correctly.

--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.comeaucomputing.com/learn/faq/
Other sites:
http://www.josuttis.com -- C++ STL Library book
http://www.sgi.com/tech/stl -- Standard Template Library

[E. Robert Tisdale]

Alvin wrote:

I'm curious as to your opinions on explicitly inlining function?
They only way to explicitly inline code is to manually inline code.
I'm talking about functions as members of a class.
For example, so class A defines
operator==() and operator!=():

> cat class_a.h:
class A {
public:
A(void);
bool operator==(const A& rhs) const;
inline // not necessary
bool operator!=(const A& rhs) const;
// ...
};

inline bool A::operator!=(const A& rhs) const {
return !(*this == rhs);
}

Is it something that should be done by the programmer
or should we assume that compiler optimisations will take care of it?
Your compiler may choose to inline operator!= automatically
even if you don't use the inline qualifier.
Your compiler may choose *not* to inline operator!= automatically
even if you *do* use the inline qualifier.

The real purpose of the inline qualifier
is to help the compiler with *linkage*.
If you include your header file in two different translation units
then try to link them together,
you'll get error messages from your link editor:
cat class_a.h #ifndef GUARD_CLASS_A_H
#define GUARD_CLASS_A_H 1

class A {
private:
// representation
int I;
public:
// operators
bool operator==(const A& rhs) const;
bool operator!=(const A& rhs) const;
// constructors
A(int i): I(i) { }
};

bool A::operator!=(const A& rhs) const {
return !(*this == rhs);
}

#endif//GUARD_CLASS_A_H
cat class_a.cpp #include "class_a.h"

bool A::operator==(const A& rhs) const {
return I == rhs.I;
}
g++ -Wall -ansi -pedantic -c class_a.cpp
cat main.cpp #include <iostream>
#include "class_a.h"

int main(int argc, char* argv[]) {
A x(13), y(42);
std::cout << (x != y) << std::endl;
return 0;
}
g++ -Wall -ansi -pedantic -o main main.cpp class_a.o

class_a.o(.text+0x0): \
In function `A::operator!=(A const&) const':
: multiple definition of `A::operator!=(A const&) const'
/tmp/cc6QaYwA.o(.text+0x100): first defined here
collect2: ld returned 1 exit status

Use the inline qualifier for A::operator!=
and the problem goes away.

[E. Robert Tisdale]

Thomas Matthews wrote:

In my opinion, functions and methods should be inlined
when the execution cost of their content is less than
or equal to the function call & return overhead; provided
the function has already been tested as a non-inlined
function.

Exceptions:
1. Development.
Many compilers have problems providing debugging
information for inlined functions.

2. Deliverable headers.
Interfaces for the external customer, such as
libraries, should not have inlined functions;
or change the design so that the delivered headers
do not contain inlined code.

Again, this is my opinion. Yours may differ.

Remember that the keyword "inline" is only a suggestion
to the compiler. The compiler may already be inlining
the function (or eliminating it).

Don't worry about optimizations
until the project works correctly.

You are confused.
Take a look at any quality implementation of the standard library.
You will find that it depends upon heavy use of inline functions
to make the code easier to read, understand and maintain
without sacrificing performance or efficiency.

The real benefit of inline functions [and operators]
is that they allow programmers to decompose large functions
into smaller functions without concern for how
doing so will effect performance.

I prefer to make all functions inline functions
and let the optimizing compiler decide
whether to inline them or not.

[Richard Herring]

In message <n0***************@newssvr17.news.prodigy.com>, Thomas
Matthews <Th*************************@sbcglobal.net> writes

Alvin wrote:

Hello all,
I'm curious as to your opinions on explicitly inlining function? I'm
talking
about functions as members of a class. For example, so class A defines a
operator==() and a operator!=():
class_a.h:
class A
{
public:
A();
bool operator==(A &rhs);
inline bool operator!=(A &rhs);
...
};
bool A::operator!=(A &rhs)
{
return !(*this == rhs);
}
Is it something that should be done by the programmer or should we
assume
that compiler optimisations will take care of it?

In my opinion, functions and methods should be inlined
when the execution cost of their content is less than
or equal to the function call & return overhead; provided
the function has already been tested as a non-inlined
function.

Exceptions:
1. Development.
Many compilers have problems providing debugging
information for inlined functions.

2. Deliverable headers.
Interfaces for the external customer, such as
libraries, should not have inlined functions;
or change the design so that the delivered headers
do not contain inlined code.

3. Compilation time considerations.
Defining functions inline may require your headers to #include many more
files, which can adversely affect the compilation time of everything
which includes them. If the (non-inline) function is defined elsewhere,
separating implementation from interface, this doesn't arise.
Again, this is my opinion. Yours may differ.

Remember that the keyword "inline" is only a suggestion
to the compiler. The compiler may already be inlining
the function (or eliminating it).

Don't worry about optimizations until the project
works correctly.

--
Richard Herring

[Richard Herring]

In message <d5**********@nntp1.jpl.nasa.gov>, E. Robert Tisdale
<E.**************@jpl.nasa.gov> writes

Thomas Matthews wrote:

In my opinion, functions and methods should be inlined
when the execution cost of their content is less than
or equal to the function call & return overhead; provided
the function has already been tested as a non-inlined
function.
Exceptions:
1. Development.
Many compilers have problems providing debugging
information for inlined functions.
2. Deliverable headers.
Interfaces for the external customer, such as
libraries, should not have inlined functions;
or change the design so that the delivered headers
do not contain inlined code.
Again, this is my opinion. Yours may differ.
Remember that the keyword "inline" is only a suggestion
to the compiler. The compiler may already be inlining
the function (or eliminating it).
Don't worry about optimizations
until the project works correctly.

You are confused.
Take a look at any quality implementation of the standard library.
You will find that it depends upon heavy use of inline functions
to make the code easier to read, understand and maintain
without sacrificing performance or efficiency.

The real benefit of inline functions [and operators]
is that they allow programmers to decompose large functions
into smaller functions without concern for how
doing so will effect performance.

I prefer to make all functions inline functions
and let the optimizing compiler decide
whether to inline them or not.

Some of us prefer to separate interface and implementation, and not
worry about optimization until we know it's needed. Inline functions
increase coupling, which is usually regarded as a bad thing.

--
Richard Herring

[E. Robert Tisdale]

Richard Herring wrote:

3. Compilation time considerations.
Defining functions inline may require your headers to #include many more
files, which can adversely affect the compilation time of everything
which includes them. If the (non-inline) function is defined elsewhere,
separating implementation from interface, this doesn't arise.
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
inline *and* external function definitions:
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.