stdafx.h 用于所有头文件或仅相关答案

【问题标题】：stdafx.h for all header files or only the pertinentstdafx.h 用于所有头文件或仅相关
【发布时间】：2016-01-04 22:58:49
【问题描述】：

当使用 Microsoft 的优化编译设计 -stdafx.h - all 包含的想法应该只出现在此文件中。或者它只是编译密集型组件？

如果坚持all“规则”，我会实现更快更高效的编译设计吗？

stdafx.h：

... Standard C++ includes

#include "Base.h"
#include "Super.h"

Base 和 Super 头文件和 cpp 文件仅包含 stdafx.h 头文件

【问题讨论】：

恕我直言，stdafx.h 导致的问题多于解决的问题。预编译的头文件应该在 huge 构建中真正发挥作用。
嗯，为什么要投反对票？
我相信您会希望对最流行的包含进行预编译。但这是我的看法。当一个巨大的预编译头文件中只有几个定义时，我看不出它如何加快编译速度。
您还可以衡量构建性能。存储设备更快，PC 也更快。测量 10 次使用预编译的头文件和 10 次没有的重建。计算平均构建时间。节省的时间是否显着？再次执行相同操作，只重新编译一个文件。节省的时间仍然很重要吗？
的想法是所有包含都应该只出现在这个文件中不。我说只把外部库的头文件放在这个文件中或者至少通常不会更改的标题。

标签： c++ compiler-optimization stdafx.h

【解决方案1】：

在使用 Microsoft 的快速编译设计 -stdafx.h 时，所有包含都应该只出现在此文件中。

正如 @drescherjm 评论的那样，并非所有标题都应放在 stdafx.h 中。

此外，即使标题出现在stdafx.h 中，也并不意味着它应该从cpp 文件中消失。至少，根据4 Ways Precompiled Headers Cripple Your Code（虽然不是关于微软，但同样的原则，强调我的）：

Apple 的 iOS 项目模板从 Prefix.pch 开始，包括 Foundation 和 UIKit。从编译速度的角度来看，这很有意义。问题是人们注意到并说，“那些文件已经被隐式包含了。所以我不需要再次包含它们。”在发现这种副作用后，一些程序员开始将更多的头文件转储到 Prefix.pch 中。因为嘿，那么您就不必再次#import 它了。

目的从“让这个项目尽可能快地编译”转变为“节省自己的打字时间”。 Stack Overflow question 反映了这一点，问道：“为什么两者都有？”甚至prefix header 的维基百科条目也反映了这个错误的结论：“因此，没有必要明确包含上述任何文件。”这种误解很普遍。

这是完全错误的。

....

问题是要成功编译一个文件，仅仅拥有成对的头文件（.h）和实现（.m）是不够的。您还需要 Prefix.pch - 不是因为它们是预编译的，而是因为它们被隐式包含。

他们给出了几点，基本上是在阐述它打破依赖概念的想法。

【讨论】：

你需要解释Precompiled headers are not supposed to minimize **number** of includes. 问题不在于包含多少次标题？它关于 where（stdafx.h 或其他地方）包含该标头以实现优化编译的目标
@JakeM 已更新。要回答您的“stdafx.h 或其他地方”问题：根据给定的建议，听起来应该正常放置文件 .h，因为它不会是预编译的标头，此外，一些应该放在stdafx.h以提高编译速度。