我是否需要 .CPP 文件?仅使用标头并使所有内容内联?
具体来说,是 GCC 4.6.1。
我知道 CPP 文件用于将接口与实现分开;现在对此不感兴趣。
看看 this,我看不出有什么理由不只使用标头和所有函数都是内联的。
性能是一个问题,但我不认为这种方法会让事情变慢。我不想要的是通常会内联的关键部分变得更慢,因为一切都是内联的。如果这是有道理的话。
GCC 4.6.1, specifically.
I am aware that CPP files serve to separate interface from implementation; that's not of interest right now.
Looking at this, I don't see any reason not to use only headers and all functions inline.
Performance is a concern, but I don't see that such an approach could make things slower. What I don't want, is to have critical sections which would usually be inlined, become slower because everything is inline. If that makes sense.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
主要问题确实是编译时间。
如果所有内容都包含在单个“主”编译单元中,那么如果您更改单个文件中的单个字符,则所有内容都必须重新编译。
另一方面,完全重建很可能比使用多个编译单元更快(在这种情况下,相同的标头必须编译多次,并且链接器将具有对于单个编译单元,每个头只需要处理一次,链接器的工作非常简单)
对于多个 .cpp 文件,您可以对其中一个文件进行更改,并且只需重新编译 < em>那个 文件。
但一些流行的库是仅包含头文件的。这绝对是可行的。
就性能而言,它应该相同或更快。您为编译器提供了对整个代码的完全可见性,这意味着它可以轻松地跨函数调用进行优化,并内联任何它喜欢的内容。
请注意,您永远不会强制编译器进行内联。
inline
关键字(以及具有相同效果的其他技巧)不会告诉编译器“这必须是内联的”。但是,通过抑制单定义规则 (ODR),它们允许您将一个定义包含到多个编译单元中,因此编译器可以更轻松地内联(如果它选择这样做的话)。但这意味着您无需担心所有内容都会被内联。编译器只会内联尽可能多的内容。
The main problem is compilation time, really.
If everything is included into a single "master" compilation unit, then everything has to be recompiled if you change a single character in a single file.
On the other hand, a full rebuild will very likely be faster than if you'd used multiple compilation units (in which case, the same headers would have to be compiled multiple times, and the linker would have more work to do. With a single compilation unit, each header only needs to be processed once, and the linker's job is pretty trivial)
With multiple .cpp files, you can make a change in one of them, and only have to recompile that file.
But several popular libraries are header-only. It's definitely viable.
Performance-wise, it should be the same or faster. You're giving the compiler full visibility over your entire code, which means it can easily optimize across function calls, and inline anything it likes.
And note that you're never forcing the compiler to inline. The
inline
keyword (and other tricks which have the same effect) do not tell the compiler that "this must be inlined". But by suppressing the one-definition-rule (ODR), they allow you to include a definition into multiple compilation units, and so it becomes easier for the compiler to inline, if it chooses to do so.But that means you don't need to worry about everything being inlined. The compiler will only inline as much as it makes sense to do.
以下是不这样做的一些原因:
Here are some reasons not to:
除了性能和内联之外,有些事情您无法仅使用标头来完成,例如类的
static
字段。也就是说,大多数(如果不是全部)
STL
都是标头,大部分Boost
也是如此。至于内联方法/函数 - 这并不重要。编译器比您更清楚要做什么,并且可能会忽略
inline
关键字(使函数成为非内联),或者相反,使函数调用内联,即使该函数未声明为内联。Performance and inlining aside, there are things you can't do with headers-only, such as
static
fields of a class.That said, most (if not all) of
STL
is headers-only, as is most ofBoost
.As for inline methods/functions - it doesn't really matter. The compiler knows better than you what to do, and may ignore
inline
keywords (making a function non-inline) or to the contrary, make a function call inline even if the function wasn't declared as such.如果所有函数都是“内联”的,那么您的二进制文件将会更大,这可能会导致性能下降。您应该只内联非常小的且经常调用的函数。
If all functions will be "inline" then yours binary file will be bigger and this could lead to less performance. You should inline only very small and often called functions.