预编译头设计问题
我有使用预编译标头的代码。 （以前由其他人完成）
其中包含几个 .h 文件。
如果我的类使用当前不在现有预编译标头中的通用 .h 文件，那么将它们扔进去会有什么真正的好处吗？也许编译速度很快，但我想它也会清理一下类/标头吗？
预编译标头的注意事项是什么？
I have code that uses a pre-compiled header. (previously done by someone else)
In it, they are including several .h files.
If I have classes that use common .h files that are not currently in the existing pre-compiled header, would tossing them in there be of any real benefit? Maybe compilation speed, but I was thinking it would clean up the classes/headers a bit too?
What are do's and don't with pre-compiled headers?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
请勿依赖预编译标头中包含的标头来进行“代码清理”，方法是从其他源文件中删除这些标头。如果您想停止使用 PCH，这将是一场噩梦。您始终希望每个源文件中的依赖项都是明确的。只需将它们包含在两个地方即可 - 这没有什么害处（假设您有适当的包含防护措施）。
由多个源文件包含的头文件是包含在 PCH 中的良好候选者（特别是如果它很长）。我发现我并没有太认真地对待这个建议，只将很少更改的标头放入 PCH。但是，这取决于您的整体项目结构。如果您经常进行完整构建，请务必避免此建议。如果您想最大程度地减少增量重建的工作，那么这是一个考虑因素。根据我的经验，重建 PCH 相对较快，而且一般情况下（在大多数情况下）编译的整体加速远远超过了其成本。我不确定是否所有 PCH 系统都足够聪明，能够弄清楚当 PCH 中包含的标头发生更改时不需要重建每个源文件（VC++ 是），但明确地
#includeing每个翻译单元中您需要的一切肯定会促进这一点（您不应该不依赖PCH中包含的内容的另一个原因）如果您的编译器支持显示
#include 编译期间每个文件的树，这对于识别应包含在 PCH 中的标头（显示最多的标头）有很大帮助。我最近在我正在从事的一个项目中经历了这个过程（该项目已经使用 PCH，但不是最佳的），并将 750K 行 C++ 的构建速度从大约 1.5 小时缩短到 15 分钟。DO NOT rely on headers being included by your precompiled header for "code cleanup" by removing those headers from your other source files. This creates a nightmare if you ever want to stop using PCH. You always want your dependencies to be explicit in every source file. Just include them in both places -- there is no harm in it (assuming you have appropriate include guards in place).
A header file that is included by multiple source files is a good candidate for inclusion in the PCH (particularly if it is lengthy). I find that I don't take the advice too seriously to only put headers that rarely change into the PCH. But, this depends on your overall project structure. If you frequently do full builds, definitely avoid this advice. If you want to minimize the work in incremental rebuilds, then it's a consideration. In my experience, rebuilding the PCH is relatively fast, and the cost of this is far outweighed by the overall speedup of compilation in general (in most cases). I'm not sure if all PCH systems are smart enough to figure out that every source file does not need to be rebuilt when a header included in the PCH changes (VC++ is), but explictly
#includeing everything you need in every translation unit will surely facilitate this (another reason you should not rely on what is included by your PCH)If your compiler supports an option to show the
#includetree for each file during compilation, this can be a great help to identify headers that should be included in the PCH (the ones that show up the most). I recently went through this on a project I'm working on (which was already using PCH, but not optimally) and sped up the build of 750K lines of C++ from roughly 1.5 hours to 15 minutes.将不变的系统包含放入预编译头中。这将加快编译速度。不要将您自己可能更改的任何头文件放入预编译头中，因为每次更改它们时，您都必须重建整个预编译头。
Put non-changing system includes into the precompiled header. That will speed up compilation. Don't put any of your own header files that you might change into the precompiled header, because each time you change them you will have to rebuild the entire precompiled header.
这是一个权衡：系统/库标头肯定会进入 PCH，这取决于您项目中的标头。
我们的项目有大量生成的代码，与项目的其他部分相比，这些代码的更改频率要低得多。这些标头位于 PCH 中，因为在每个单独的文件中处理它们需要花费大量时间。如果您更改它们，成本会很高，但您必须权衡该成本与将它们保存在文件中更频繁的较小节省。
It is a trade-off: system/library headers definitely go in the PCH, for ones in your project it depends.
Our project has a large amount of generated code that is changed much less frequently that other parts of the project. These headers go in the PCH because they take a lot of time to process in each individual file. If you change them it is expensive, but you have to weigh that cost against the more frequent smaller savings of having them in the file.