将声明和实施压缩到 HPP 文件中
我读过一些关于在 C++ 中保留标头的必要性/适用性/实用性的文章，但我似乎找不到任何可靠的理由为什么/何时应该或不应该执行上述操作。我知道 boost 使用 .hpp 文件向最终用户提供模板函数，而不需要关联的 .cpp 文件，并且这种想法部分源自浏览该代码。看起来这将是一种传递单个文件模块（例如新的 Wt 或 Qt 小部件）的便捷方法（仍然坚持每个 .h 一个类约定）。
但是，假设您可以访问实现（例如在 OSS 的上下文中），为某人提供一个包含标头声明和实现的单个 .hpp 文件，是否存在任何负面的技术实现。从编译器/链接器的角度来看，它是否有任何负面影响？
对此的任何意见或观点将不胜感激。
I've read a few of the articles about the need / applicability / practicality of keeping headers around in C++ but I can't seem to find anywhere a solid reason why / when the above should or should not be done. I'm aware that boost uses .hpp files to deliver template functions to end users without the need for an associated .cpp file, and this thought is partially sourced off browsing through that code. It seems like this would be a convenient way to deliver single file modules of say a new Wt or Qt widget (still sticking to the one class per .h convention).
However are there any negative technical implementations for giving somebody a single .hpp file with both the header declaration and implementation assuming you have no problem with them having access to the implementation (say in the context of OSS). Does it for instances have any negative implications from the compiler's / linker's perspective?
Any opinions or perspectives on this would be appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
错误的动词：它不是“没有需要”，而是“没有 能力”。
如果 Boost 可以，他们会将库分为头文件和实现文件。事实上，只要有可能，他们都会这样做。
彻底分离的原因很简单：仅头文件项目的编译时间大大增加，因为每次重新编译应用程序的最小部分时都必须读取、解析和编译关联的头文件。
仅当您碰巧重新编译该特定目标文件时才需要编译实现文件。
大型 C 和/或 C++ 项目需要几个小时来编译。这些使用将头文件和目标文件完全分开。如果他们只使用头文件，我敢打赌编译时间将以天而不是小时来衡量。
但对于 Boost 的许多库来说，事实是模板定义可能不会与其声明驻留在单独的编译单元中，因此这是不可能的。
Wrong verb: it’s not “without the need”, it’s “without the ability”.
If Boost could, they would separate their libraries into headers and implementation files. In fact, they do so where ever possible.
The reason for a clean separation is simple: compilation time for header-only projects increases tremendously because associated header files have to be read, parsed and compiled every time you recompile the tiniest part of your application.
Implementation files only need to be compiled if you happen to recompile that particular object file.
Large C and/or C++ projects take hours to compile. And these use a clean separation into header and object files. If they would only use header files, I’m betting the compilation time would be measured in days instead of hours.
But for many of Boost’s libraries, the fact is that template definitions may not reside in a separate compilation unit than their declarations so this is simply not possible.
仅 .hpp 库的主要缺点是它们无法引用预编译模块。 .hpp 中存在的所有代码以及库中的所有代码都必须添加到您的应用程序中。这会增加二进制文件的大小，并在多次使用该库的系统上产生冗余二进制文件。
The major negative aspect of .hpp-only libraries is that they cannot refer to a precompiled module. All of the code present in the .hpp and hence all of the code in the library must be added to your application. This increases the size of the binary and makes for redundant binaries on such a system that uses the library more than once.
使用模板，您没有真正的选择。理论上，
export允许您将接口与实现分离，但只有一个编译器 (Comeau) 真正支持此1，并且它已从 C++0x 中删除。无论如何，尝试将非模板函数的实现放入标头中会导致一个明显的问题：单一定义规则仍然有效，因此如果您在多个翻译单元中定义相同的函数，就会遇到问题。链接器通常会给出一个错误，指出同一符号已被定义多个。
1尽管主要是 EDG 编译器前端真正支持它，所以其他基于 EDG 的编译器（例如 Intel 的编译器）也支持
导出在某种程度上，尽管他们没有记录它，所以你不能太依赖他们。With templates you have no real choice. In theory,
exportallows you to separate the interface from the implementation, but only one compiler (Comeau) really supports this1, and it's being dropped from C++0x.In any case, trying to put the implementations of non-template functions into headers leads to one obvious problem: the One Definition Rule remains in effect, so if you define the same function in more than one translation unit, you have a problem. The linker will typically give an error saying the same symbol has been defined more than one.
1Though it's mostly the EDG compiler front-end that really supports it, so other EDG-based compilers, such as Intel's also support
exportto some degree, though they don't document it, so you can't depend on much with them.