To inline or not to inline?

Discussion in 'C++' started by Alvin, May 5, 2005.

  1. Alvin

    Alvin Guest

    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::eek:perator!=(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, May 5, 2005
    #1
    1. Advertising

  2. * 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::eek:perator!=(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?
     
    Alf P. Steinbach, May 5, 2005
    #2
    1. Advertising

  3. 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::eek:perator!=(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
     
    Thomas Matthews, May 5, 2005
    #3
  4. 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::eek:perator!=(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::eek:perator!=(const A& rhs) const {
    return !(*this == rhs);
    }

    #endif//GUARD_CLASS_A_H

    > cat class_a.cpp

    #include "class_a.h"

    bool A::eek:perator==(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::eek:perator!=(A const&) const':
    : multiple definition of `A::eek:perator!=(A const&) const'
    /tmp/cc6QaYwA.o(.text+0x100): first defined here
    collect2: ld returned 1 exit status

    Use the inline qualifier for A::eek:perator!=
    and the problem goes away.
     
    E. Robert Tisdale, May 5, 2005
    #4
  5. 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.
     
    E. Robert Tisdale, May 5, 2005
    #5
  6. In message <n0ree.2184$>, Thomas
    Matthews <> 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::eek:perator!=(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, May 6, 2005
    #6
  7. In message <d5djcm$qvr$>, E. Robert Tisdale
    <> 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
     
    Richard Herring, May 6, 2005
    #7
  8. 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.
     
    E. Robert Tisdale, May 6, 2005
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Abhi
    Replies:
    2
    Views:
    741
    E. Robert Tisdale
    Jul 3, 2003
  2. Replies:
    3
    Views:
    460
  3. Daniel Vallstrom
    Replies:
    2
    Views:
    1,895
    Kevin Bracey
    Nov 21, 2003
  4. Nish
    Replies:
    4
    Views:
    494
    Thomas Stegen
    Oct 8, 2004
  5. Jon Slaughter

    to inline or not to inline

    Jon Slaughter, Apr 20, 2007, in forum: HTML
    Replies:
    9
    Views:
    351
    Andy Dingley
    Apr 20, 2007
Loading...

Share This Page