大型项目 (redux) 的 C++ header 策略

Question

我已经阅读了我能找到的有关该主题的所有内容，包括本网站上一些非常有帮助的讨论、NASA 编码指南和 Google C++ 指南。我什至买了这里推荐的“物理 C++ 设计”书(抱歉，忘了名字)并从中得到了一些有用的想法。大多数来源似乎都同意 - 头文件应该是独立的，即它们包含他们需要的内容，以便 cpp 文件可以包含头文件而不包含任何其他文件，并且它可以编译。我也明白了关于转发声明而不是尽可能包含的观点。

也就是说，如果 foo.cpp 怎么样？包括 bar.h和 qux.h , 但事实证明 bar.h本身包括 qux.h ？应该foo.cpp然后避免包含 qux.h ？ Pro:清理foo.cpp (少“噪音”)。缺点:如果有人将 bar.h 更改为不再包含 qux.h , foo.cpp神秘地开始无法编译。也会导致 foo.cpp 之间的依赖关系和 qux.h不明显。

如果您的回答是“一个 cpp 文件应该#include 它需要的每个头文件”，那么得出的逻辑结论就是几乎每个 cpp 文件都必须包含 #include <string>, <cstddef>等等，因为大多数代码最终都会使用这些，如果您不应该依赖其他一些 header ，包括它们，您的 cpp 需要明确包含它们。这在 cpp 文件中似乎有很多“噪音”。

想法？

以前的讨论:

What are some techniques for limiting compilation dependencies in C++ projects?

Your preferred C/C++ header policy for big projects?

How do I automate finding unused #include directives?

预计到达时间:受之前此处讨论的启发，我编写了一个 Perl 脚本来连续注释掉每个“include”和“using”，然后尝试重新编译源文件，找出不需要的内容。我还弄清楚了如何将它与 VS 2005 集成，因此您可以双击转到“未使用”包含。如果有人想要它，请告诉我...不过现在还处于实验阶段。

Answer 1

If your answer is "a cpp file should #include every header it needs", taken to its logical conclusion that would mean that pretty much every cpp file has to #include <string>, <cstddef> etc. since most code will end up using those, and if you're not supposed to rely on some other header including them, your cpp needs to include them explicitly.

是的。这就是我喜欢的方式。

如果“噪音”太大而无法忍受，那么可以有一个“全局”包含文件，其中包含常用的、通用的包含集(如许多 Windows 程序中的 stdafx.h)，并将其包含在每个.cpp的开始文件(也有助于预编译头文件)。