c++ - 什么时候应该使用 -inl.h 文件？

Question

我刚刚在Google C++ 编码风格指南中注意到了这个项目——我不太明白。

如果我将内联方法或函数放在其他文件包含的头文件之外的文件中，它将不是该类的方法；它只能用于包含它的代码位。那么为什么还要有这样的 -inl.h 文件呢？

另外，为什么我们还要内联长函数呢？（即除了在模板的情况下，当我们必须将代码放在头文件中进行实例化时）

Answer 1

我刚刚在 Google C++ 编码风格指南中注意到了这个项目——我不太明白。

一定要加一点盐来拿那个指南。许多指南旨在帮助与 Google 的遗留代码库进行交互，对于一般 C++ 开发来说并不是特别好的建议。

那么为什么还要有这样-inl.h的文件呢？

没有特别好的理由；我自己不会那样做。有些人喜欢它们，因为它最大限度地减少了主头文件中的内容量，头文件的用户通常希望阅读这些内容，并分离出他们通常不关心的实现细节。

另外，为什么我们还要内联长函数呢？

有时，我们必须：模板定义必须在任何实例化模板的翻译单元中可用，因此它们（通常）需要在标题中。

有时，我们希望：通过在标题中实现内联函数，我们不必担心为它构建和链接单独的翻译单元。这样可以更方便地分发库；可能以更长的构建时间为代价。

Answer 2

这通常用于长函数模板。常规头my_functions.h只包含声明，实现文件my_functions-inl.h包含实现。原因是函数模板不能放在 .cpp文件中。请注意，Xh 文件包含 X-inl.h 文件，而不是相反。

其他库有不同的命名约定：例如，一些 Boost 库使用 .hpp 作为模板头文件，使用 .ipp 作为模板实现文件。

Answer 3

根据最新的谷歌编码风格，不再允许 https://google.github.io/styleguide/cppguide.html#Variable_Names

最好将模板和内联函数的定义与其声明放在同一个文件中。这些构造的定义必须包含在每个使用它们的 .cc 文件中，否则程序可能无法在某些构建配置中链接。如果声明和定义在不同的文件中，包括前者应该传递地包括后者。不要将这些定义移动到单独包含的头文件（-inl.h）中；这种做法在过去很常见，但已不再被允许。