To inline or not to inline?

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

* Alvin:[color=blue]
>
> 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?[/color]

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?

Alvin wrote:[color=blue]
> 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?
>[/color]

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

Alvin wrote:
[color=blue]
> I'm curious as to your opinions on explicitly inlining function?[/color]

They only way to explicitly inline code is to manually inline code.
[color=blue]
> I'm talking about functions as members of a class.
> For example, so class A defines
> operator==() and operator!=():
>[color=green]
> > cat class_a.h:[/color]
>
> class A {
> public:
> A(void);
> bool operator==(const A& rhs) const;
> inline // not necessary
> bool operator!=(const A& rhs) const;
> // ...
> };
>[/color]
inline[color=blue]
> 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?[/color]

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:
[color=blue]
> cat class_a.h[/color]
#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
[color=blue]
> cat class_a.cpp[/color]
#include "class_a.h"

bool A::operator==(const A& rhs) const {
return I == rhs.I;
}
[color=blue]
> g++ -Wall -ansi -pedantic -c class_a.cpp
> cat main.cpp[/color]
#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;
}
[color=blue]
> g++ -Wall -ansi -pedantic -o main main.cpp class_a.o[/color]
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.

Thomas Matthews wrote:
[color=blue]
> 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.[/color]

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.

In message <n0ree.2184$Yg4.92@newssvr17.news.prodigy.com>, Thomas
Matthews <Thomas_MatthewsSpamBotsSuck@sbcglobal.net> writes[color=blue]
>Alvin wrote:[color=green]
>> 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?
>>[/color]
>
>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.[/color]

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.
[color=blue]
>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.
>[/color]

--
Richard Herring

In message <d5djcm$qvr$1@nntp1.jpl.nasa.gov>, E. Robert Tisdale
<E.Robert.Tisdale@jpl.nasa.gov> writes[color=blue]
>Thomas Matthews wrote:
>[color=green]
>> 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.[/color]
>
>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.[/color]

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

Richard Herring wrote:
[color=blue]
> 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.[/color]

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:
[color=blue]
> cat file.h[/color]
#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
[color=blue]
> cat file.cc[/color]
#undef EFINE_INLINE
#include "file.h"

double f(double x) {
return x*(x + 2.0) + 1.0;
}
[color=blue]
> g++ -DEFINE_INLINE -Wall -ansi -pedantic -O3 -c file.cc
> nm --demangle file.o[/color]
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.