# include < bits/stdc + + . h > 在 C + + 中是如何工作的？

小开

这个头文件不是 C + + 标准的一部分，因此是不可移植的，应该避免。

此外，即使在标准中有一些全部包含的标头，你也应该避免使用它来代替特定的标头，因为编译器必须在每次编译翻译单元时实际读入并解析每个包含的标头(包括递归包含的标头)。

小开

最佳答案

它基本上是一个头文件，也包括每个标准库和 STL 包含文件。我能想到的唯一目的就是为了考试和教育。

例如 GCC 4.8.0/bit/stdc + + . h 源。

使用它会包含很多不必要的内容，并增加编译时间。

编辑: 正如 Neil 所说，这是一个针对预编译头文件的实现。如果您为预编译正确地设置了它，事实上，它可以根据您的项目加快编译时间。(https://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html)

但是，我建议您花些时间了解每个 sl/stl 头文件，并单独包含它们，除了预编译目的之外，不要使用“超级头文件”。

小开

ABc0是一个预编译头的实现文件。

从软件工程的角度来看，最小化 include 是一个好主意。如果使用 < bits/stdc + + 。它实际上包含了大量的文件，这些文件可能是程序不需要的，因此不必要地增加了编译时间和程序大小。[编辑:正如@剑鱼在评论中指出的那样，输出程序的大小不受影响。但是，最好只包含您实际需要的库，除非它是某种竞争对手 ]

但是在比赛中，当你想减少在做家务上浪费的时间时，使用这个文件是一个好主意，特别是当你的排名是时间敏感的时候。

它适用于大多数在线评委、编程竞赛环境，包括 ACM-ICPC (分区赛、地区赛和世界总决赛)和许多在线评委。

它的缺点是:

增加了编译时间。

使用 GNU c + + 库的内部非标准头文件，因此不会在 MSVC、 XCode 和许多其他编译器中编译

小开

不幸的是，到目前为止，这种方法还不是可移植的 C + + 。

所有标准名称都在名称空间 std中，而且您不能知道哪些名称是由 include 和 header 定义的没有(换句话说，在使用 #include <vector>时，实现直接或间接声明名称 std::string是完全合法的)。

尽管如此，语言还是要求你知道并告诉编译器哪个标准头包含了标准库的哪个部分。这是一个可移植性错误的来源，因为如果你忘记了例如 #include <map>，但使用 std::map，这是可能的程序编译无论如何都是静默的，没有警告的特定版本的特定编译器，你可能会得到错误，只有稍后当移植到另一个编译器或版本。

在我看来，没有任何有效的技术借口可以解释为什么这对普通用户是必要的: 编译器二进制文件可以内置所有标准名称空间，这实际上可以提高性能，甚至比预编译头(例如，使用完美的哈希查找，删除标准头解析或加载/解组等)。

标准头的使用简化了编译器或标准库的生命周期，仅此而已。这不是帮助用户的东西。

然而，这就是语言的定义方式，你需要知道哪个头定义了哪些名字，所以计划一些额外的神经元烧毁在无意义的配置中，以记住这一点(或者尝试找到和 IDE，自动添加你使用的标准头，并删除那些你不使用的... 一个合理的选择)。