例如，在<algorithm>中，函数equal_range返回pair，因此我可以假设，如果我#include <algorithm>，<utility>为{{1} }} d？
答案 0 :(得分：5)
从来没有保证包含其他标头所依赖的头文件。幸运的是，通常的做法（虽然不是100％的时候都不确定）标题可以防止多次包含 - 这意味着您可以根据需要多次#include它们而不会造成伤害。
答案 1 :(得分：4)
您应该始终包含所需内容，不能依赖于所有实现，包括另一个标头中的相同标头集。
在您的示例中，如果函数返回一对，您可以合理地确定声明了pair类，但没有任何要求实现包含<utility>的其余部分。
事实上，不可能使用标准中显示的标题来实现标准库，因为有一些循环引用。实现必须将它们拆分为较小的部分，并在所需的<>标头中包含这些子标头。
例如，海湾合作委员会小组正在努力减少包含量，以加快编制时间。
答案 2 :(得分：2)
好的，迟到的答案，但无论如何我都会加上这个。
关于<iostream>标题。在C ++ 98和C ++ 03中，该标准不保证它包含<istream>和<ostream>，这意味着您无法保证可以使用例如std::endl和std。 <cstdio>。并且至少有一个编译器坚持要对它进行形式化（尽管标准中的所有非规范性示例都显示了意图）！
好吧，我不记得是谁首先指出了它，但在[comp.lang.c ++]中对它进行了讨论。几次。最后詹姆斯坎泽，祝福他的灵魂（他还没有死，事实上他已经在这里了），把它交给委员会，并且它已经修复为C ++ 0x。
所以，现在有一个你可以依赖的头依赖。
哈利路亚！
但另一方面，C ++ 0x增加了关于哪些头可以在全局命名空间和<stdio.h>命名空间中放置哪些名称的混淆。现在，对应于C库头的任何标准库头都可以自由地污染全局命名空间，并且符合要求。所以现在没有必要包括{{1}}，但现在明智的做法是包含{{1}}并接受保证全局命名空间污染。
干杯＆amp;第h。，
答案 3 :(得分：1)
是的，你不应该假设包含标题。我一直在玩包含标题一段时间，你知道我发现当涉及到矢量和字符串等头文件时，你“几乎”确定你是从某个地方包含它们。 是的，但只有在你玩的时候，这些东西才是好的。我建议你总是包括标题。
答案 4 :(得分：1)
无法保证，但由于<algorithm>内部使用了对，因此通常应该包括它。有一些方法可以确保头文件只包含一次：
#pragma once http://en.wikipedia.org/wiki/Pragma_once
#ifndef MY_H
#define MY_H
//header code
#endif /* MY_H */
通常一个好的库将包含所有需要编译的文件，并且这些文件将使用这种机制来确保它们只被包含一次。
此规则有时会出现例外情况，特别是在私有（个人而非标准）库中，其中包含的头文件按其编译所需的顺序放置。在这种情况下，如果你有三个包含，可能第二个包括使用第一个和第二个中的第一个和第三个的代码。
最佳方法是包含您可以直接访问所使用的数据结构所需的所有内容。