C++ tip: Considering the use of the inline keyword

Topics: C/C++
Technologies: C++

The C++ "inline" keyword marks methods as inlineable by the compiler to improve performance. But today's compilers seem to inline methods even if they aren't marked with "inline". So is there a need for the "inline" keyword? This article does quick benchmarking of multiple ways to define method bodies, with and without "inline", to see if there's any value to the keyword.

Inline methods

When a compiler inlines a method, it skips the overhead of jumping to and from the method code and pushing and popping variables from the stack. For light-weight methods, this overhead can swamp the runtime cost of the method's body. This is particularly the case for "get" accessor methods that simply return internal object state, such as the size of an STL <vector>.

By skipping all the method call overhead, inlining improves performance. But inlining is such a good optimization, compilers now seem to do it for most every method who's body is defined in a ".h" file, whether or not the method is marked with "inline".

What is the point of marking a method "inline"?

To see the point, let's test several variations of a simple "get" method"

  • Define the method within the class { } in the ".h" file:
    • Leave it unmarked.
    • Mark it with "inline".
  • Define the method after the class { }, but in the same ".h" file:
    • Leave it unmarked.
    • Mark it with "inline".
  • Declare the method in the ".h" file, but define it in a separate ".cc" file:
    • Leave it unmarked.
    • Mark it with "inline".
  • Define the method within the class { } in the ".h" file:
    • Mark it with "virtual".

With these variations, we can look at what messages the compiler provides, and benchmark performance to verify when a method actually gets inlined.


Compilation immediately rejects two of the above variations:

  • Define the method after the class { }, but in the same ".h" file
    • Leave it unmarked.
      • When a method is defined at the end of the ".h" file, but not marked "inline", the compiler creates a full method body definition every time the ".h" file is included. This yields duplicate symbols that cause linker errors.
  • Declare the method in the ".h" file, but define it in a separate ".cc" file
    • Mark it with "inline".
      • When a method is marked as "inline", the compiler expects to find the method body in the ".h" file. It ignores any definition outside the ".h" file, such as in a ".cc" file. If the method isn't found in a ".h" file, the compiler complains and the linker fails to link the missing method.

The plot below shows the remaining variations benchmarked using g++, clang++, and icpc with maximum compiler optimizations. The vertical axis is run time and lower is better. The axis numbers are intentionally omitted since the exact run time will vary based on the processor and "get" method. What matters is general notions of "high" and "low" for the three variations.


When a method is is marked "virtual", it is never inlined. These are the far right bars in the plot.

When a method's body isn't in the ".h" file, it certainly can't be inlined. These are the middle high bars in the plot.

The remaining three cases with low bars are all inlined. If the method is within the class { }, it's inlined whether or not it is marked "inline". When the method is after the class { } in the ".h" file, and marked "inline", it is inlined.


The "inline" keyword does not control inlining. Any non-virtual method defined within the class { } may be inlined.

What the "inline" keyword does is declare the programmer's intent, which enables the compiler to check that the method's definition matches that intent. So if you mark a method as "inline", but don't define the method body properly, you'll get a compiler error.

It is always good practice to clearly state your intent to a compiler so that it can do more compile-time checking. So, if you want a method inlined, say so with the "inline" keyword.


Post new comment

The content of this field is kept private and will not be shown publicly.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.
  • Web page addresses and e-mail addresses turn into links automatically.

More information about formatting options

Nadeau software consulting
Nadeau software consulting