I just noted this item in the Google C++ Coding Style Guide - and I don\'t quite get it.
If I put an inline method or function in a file other than the header included b
This is often done for long function templates. The regular header my_functions.h
only contains the declarations, and the implementation file my_functions-inl.h
contain the implementations. The reason is that function templates cannot be put in .cpp files. Note that the X.h file includes the X-inl.h file, not the other way around.
Other libraries have different naming conventions: e.g. some of the Boost libraries use .hpp for template headers and .ipp for template implementation files.
According to latest Google coding style, it is no longer allowed https://google.github.io/styleguide/cppguide.html#Variable_Names
Prefer placing the definitions for template and inline functions in the same file as their declarations. The definitions of these constructs must be included into every .cc file that uses them, or the program may fail to link in some build configurations. If declarations and definitions are in different files, including the former should transitively include the latter. Do not move these definitions to separately included header files (-inl.h); this practice was common in the past, but is no longer allowed.
I just noted this item in the Google C++ Coding Style Guide - and I don't quite get it.
Do take that guide with a pinch of salt. Many of the guidelines are intended to help interact with Google's legacy codebase, and aren't particularly good advice for general C++ development.
So why even have such
-inl.h
files at all?
There's no particularly good reason; I don't do that myself. Some people like them because it minimises the amount of stuff in the main header file, which users of the header generally want to read, and separates out the implementation details, which they generally don't care about.
Also, why do we even want to inline long functions anyways?
Sometimes, we must: template definitions must be available in any translation unit that instantiates the template, so they (usually) need to be in headers.
Sometimes, we want to: by implementing a function inline in a header, we don't have to worry about building and linking a separate translation unit for it. This can make it more convenient to distribute a library; possibly at the cost of longer build times.