我正在处理一个使用 STL 的大型项目，并且对您组织 STL 的首选方式有疑问#includes。
foo.cpp需要bar.cpp，std::string那么两者都会#include <string>。第一种方法的优点是 .cpp 文件是一个独立的单元，可以在不同的项目中使用，而不必担心会丢失 .cpp 文件#include。第二种方法的优点是您可以使用编译器预编译的头文件支持，另外您可以将 STL 包装#includes在pragmas其中禁用一些警告（例如，某些 Boost 头文件在第 4 级编译时会导致警告）。
你更喜欢使用哪个？
我只包含每个源代码中真正需要的头文件，而不是“捕获所有”头文件，以保持依赖关系（以及因此编译时间）尽可能低。
无论如何，预编译的头文件都可以工作（即我依靠预编译的头文件来加速编译过程，而不是获得声明）。因此，即使通过包含的预编译头文件声明了某些内容，我仍然包含“常规”头文件，该头文件将被包含保护机制跳过，并且不会对编译时间增加任何重要内容。
因为预编译的头文件是编译器特定的东西。在我看来，优化/更改预编译头文件应该不会影响代码的正确运行。
尽可能低的依赖关系的主要优点是重构变得更容易（或者更确切地说：可行）
关于这一切的好书是来自 Lakos 的大型 C++ 设计
我所做的是将整个项目中需要的所有 STL 头文件包含在我的单个预编译头文件中，通常是默认的 StdAfx.h。预编译头文件实际上是在项目中设置的第一件事，包括所有 STL-/boost-/平台头文件和第三方库。
STL 和 boost 整齐地排列在命名空间中，因此它们也不会造成任何混淆或重叠。
在标题中，我通常使用全名，但在源文件中，在适当的时候使用命名空间 x。
您可以结合使用这两种方法：
将两个 .cpp 文件都包含在内，并将其添加到 stdafx.h。这仍然会为您提供 PCH 优化。
.cpp - 文件仍然需要#include "stdafx.h"，因此它的独立性值得商榷。但是，依赖项是明确的状态，删除 stdafx.h 包含比查找所有丢失的包含更简单。此外，标准标题 - 所有标题都应该 - 确保它们没有被包含两次。
一般来说，我同意您使每个文件“独立”的方法，即当 .cpp 添加到另一个项目或包含 .h 时，它会处理其依赖关系。
请记住，PCH 是一种权衡，它们可能会变得巨大。在 PCH 中有很多大部分未使用的代码实际上会减慢您的构建速度。不过，快速磁盘有很大帮助:)
另请注意，至少在某些版本中，在 MSVC 中启用预编译标头实际上确实会改变处理：#include "stdafx.h" 之前的声明被忽略，因此这需要是您的第一个非注释语句。丑陋的陷阱。
完全同意 John Lakos 的《Large Scale C++ Design》一书的建议。
在文件本身中声明文件所需的所有标头，无论是 .h 还是 .cpp。不要依赖其他头文件包含的文件的副作用。
列出所有包含的大型头文件会不必要地增加依赖关系并使设计非常脆弱。
哦，另一件事永远不会在头文件中使用声明。仅在您的实现文件、.cpp 文件中使用它们。
HTH。
干杯，
抢