【发布时间】：2014-11-23 14:19:56
【问题描述】：
我查找了头文件示例，但只能找到没有任何内容的简单示例。
所以我的问题是#include 像string 和vector 这样的东西在哪里？在 .h 或 .cpp 文件中？或者两者兼而有之？
【问题讨论】：
标签： c++ header include libraries
【发布时间】：2014-11-23 14:19:56
【问题描述】：
任何你需要的地方。
如果您需要在头文件中声明的内容，请将它们包含在 .h 文件中。 否则就在 .cpp 文件中。
请注意，包含 .h 文件只是文本替换，包含的 .h 文件的内容将完全插入 在包含它们的文件的开头。在#include 线的精确点。
在标准库的头文件之前包含一个属于项目的头文件是一个很好的做法，如果不需要，则永远不要包含头文件。
您应该记住的最后一件事是，在处理 大型项目 时，如果多个翻译单元共享的 .h 文件中包含许多标头，如果标头被修改，则可能会增加编译时间。通常最好只在适当的文件（.cpp 或 .h）中包含您严格要求的内容。预编译的标头也可能会有所帮助，但这与您的问题无关。
最后：不要依赖“此标头已包含在其他地方，并且我已经通过第二个标头包含它”，因为它可能会导致难以跟踪依赖项并在项目增长时支持循环依赖项。
【讨论】：
-
添加，以尽可能地强制正确包含：始终首先包含属于实现文件的标头。
-
@Deduplicator 是的。我通常会更进一步，按一般性“排序”包含：首先是文件本身，然后是我项目中的其他文件，然后是特定的第 3 方库，然后是广泛的第 3 方库（例如 Qt），然后是 Boost，最后是标准库。
-
两个 cmets：首先，我经常看到包含的相反顺序（实现文件的头除外，它总是在前）：标准库和系统头，然后是外部库，最后程序中的其他库。 （但是我不知道为什么。我想不出任何真正的理由偏爱一个订单而不是另一个订单。）其次，通常有一个例外是不依赖于头文件中的包含：允许实现文件依赖于包含在它自己的标题中。
-
"...包含的 .h 文件的内容将完全插入到包含它们的文件的开头。"这是误导。它们将包含在文件中找到
#include指令的确切位置，而不是在开头。意思是，如果你在文件的最后一行写#include，包含文件的内容将被插入到包含文件的末尾。 -
@ArneMertz：你是对的；我已经更新了答案。 where 包含标题的问题很重要。
我在哪里#include 诸如字符串和向量之类的东西？在 .h 或 .cpp 文件中？
在这方面需要考虑多个问题，尤其是当项目变得更大时（即您的项目越大，这对您的影响越大）。
就个人而言，我遵循以下规则：
如果代码需要编译头文件，则需要包含它（如果头文件在 API 中使用 std::string 声明内容，则必须包含
string，C++ 文件也是如此)-
不要包含不需要的标头（即不是“两者” - 如果您在 .h 文件中包含标头，然后包含您的 .h 文件，应该没问题）。
-
为您的项目文件组织标题优先级。这意味着如果您在 C++ 文件中有本地项目标头以及 std 和 boost 标头，您应该（可能）首先包含本地项目标头，然后是 boost，然后是 std。
这是因为 std 标头将是最受测试/最稳定的标头，也是最常用的 API（这是我的盲目假设）。如果您首先包含 std 标头，然后是项目标头（例如），因为替换是文本的，您可以不在项目标头中添加包含。这基本上会掩盖错误，因为从现在开始，您最终必须在所有其他 cpp 文件中的本地项目标头之前包含 std 标头。
【讨论】：