4

I've working on a project at work where there's loads and loads of code in the header files. If I were using Visual Studio this wouldn't be an issue, as this has pre-compiled headers etc, but this is Linux GCC code.

Anyway, its starting to become a bit of an issue with compilation times. Of course the templates are going to have to remain in the headers etc, but most of this code could be extracted into implementation files and linked against as a static library. All of the projects uses these headers and get compiled each time, so it makes sense to create a static lib.

Implementations in the header files are in-lined, or is this only a hint, like the inline keyword? This code is VERY time critical and I'm concerned about moving the implementations out of the headers. Can I achieve the same thing if I use the inline keyword as opposed to having implementations in header files?

** UPDATE ** I know that inline is only a hint to the compiler. I'm not in control of everything in the project and I just want to move everything out of the headers into a library without affecting performance. Is this actually going to be a try it and see thing? I just want to keep performance exactly the same but enhance compile time.

The Welder
  • 916
  • 6
  • 24
  • 2
    You can use precompiled headers with gcc, e.g. http://stackoverflow.com/questions/58841/precompiled-headers-with-gcc – doctorlove Nov 21 '13 at 19:45
  • If you move the implementation out of a header, then you can't (usually) declare it inline. Inline functions must be defined in each translation unit that uses them. – Mike Seymour Nov 21 '13 at 19:45
  • have you tried unity builds? http://buffered.io/posts/the-magic-of-unity-builds explicit template instanciation might help too. you could also try to split header files in implementation of the inline functions and a separate header with their definition. – Alexander Oh Nov 22 '13 at 07:30

4 Answers4

2

The inline keyword is only a hint to the compiler that it may wish to inline that function. Its real purpose is to allow you to legally "violate" the one definition rule.

In order to inline a function its body has to be visible at the point of call, which typically means that if you move the function to an implentation file it may not be inlined anymore.

But keep in mind that most likely large functions in the header will not be inlined anyway. Also consider that in many cases inlined functions may actually be slower than called functions due to a variety of architecture-specific issues.

Mark B
  • 95,107
  • 10
  • 109
  • 188
0

inline is a hint for optimization, but it is also used to work around ODR.

Consider using whole program optimization / link-time optimization instead. It allows you to have implementation in multiple files and basically everything has the same opportunity to be optimized (and inlined) as if it were in the same translation unit.

Your compile times become much quicker, but link times usually suffer, sometimes quite a bit. You don't need to enable it for debug builds though, so it can manifest a pretty immediate improvement to dev time.

Cory Nelson
  • 29,236
  • 5
  • 72
  • 110
0

If I were using Visual Studio this wouldn't be an issue, as this has pre-compiled headers etc

GCC has them too.

http://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html

Ben Voigt
  • 277,958
  • 43
  • 419
  • 720
0

The inline keyword does NOT mean that the function has to be implemented "in the line" where you define the function. As you know it is a hint for the compiler, to let it try compiling as if the few lines in the function were at the place where you call it. Thus avoiding the overhad of saving the adress to jump back, a vtable lookup etc.

Thinking it is faster called because it is in the header, is wishfull thinking (of the original guy who wrote the code).

Try it and move the implementation to the cpp file in a minimal example - main one object one inline function one call to it. Once implemented in the header and once in a cpp file. Then look at the assembly. No difference.

Marcel Blanck
  • 867
  • 7
  • 12