我正在处理一个使用 STL 的大型项目，并且对您组织 STL 的首选方式有疑问#includes。
foo.cpp 和bar.cpp 都需要std::string，那么两者都需要#include <string>。第一种方法的优点是 .cpp 文件是一个独立的单元，可以在不同的项目中使用，而不必担心丢失了#include。第二种方法的优点是您可以使用您的编译器预编译头文件支持，另外您可以将 STL #includes 包装在 pragmas 中以禁用某些警告（例如，某些 Boost 头文件在第 4 级编译时会导致警告)。
你更喜欢用哪个？
【问题讨论】：
我只包含每个源代码中真正需要的头文件，而不是“捕获所有”头文件，以尽可能降低依赖关系（以及因此编译时间）。
无论如何，预编译的头文件都可以工作（即我依靠预编译的头文件来加速编译过程，而不是获得声明）。因此，即使通过包含的预编译头文件声明了某些内容，我仍然包含“常规”头文件，该头文件将被包含保护机制跳过，并且不会对编译时间增加任何重要内容。
因为预编译头文件是编译器特定的东西。在我看来，优化/更改预编译头文件应该不会影响代码的正确运行。
依赖关系尽可能低的主要优点是重构变得更容易（或者更确切地说：可行）
关于这一切的好书是Large Scale C++ Design from Lakos
【讨论】：
我所做的是在我的单个precompiled header 中包含我将在整个项目中需要的所有 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 的《大规模 C++ 设计》一书的建议。
在文件本身中声明文件所需的所有标头，无论是 .h 还是 .cpp。不要依赖其他头文件包含的文件的副作用。
拥有一个列出所有包含的大型头文件会不必要地增加依赖关系并使设计非常脆弱。
哦，另一件事永远不会在头文件中使用声明。仅在您的实现文件、.cpp 文件中使用它们。
HTH。
干杯，
罗伯
【讨论】：