为什么我不应该 #include < bits/stdc++.h>？

在 Stack Overflow 上，包含似乎越来越常见，也许是本学年国家课程中新添加的内容。<bits/stdc++.h>

我想这些优点是模糊的：

• 你只需要写一行。#include
• 您无需查找所有内容都在哪个标准标头中。

不幸的是，这是一个懒惰的黑客，直接命名 GCC 内部标头，而不是像 和 .它破坏了便携性并养成了可怕的习惯。<string><iostream><vector>

缺点包括：

• 它可能只适用于该编译器。
• 你不知道当你使用它时它会做什么，因为它的内容不是由标准设定的。
• 即使只是将编译器升级到自己的下一个版本，也可能会破坏程序。
• 每个标准标头都必须与源代码一起解析和编译，这很慢，并且在某些编译设置下会导致大量可执行文件。

别这样！

---

更多信息：

• #include < bits/stdc++.h> 与 Visual Studio 一起无法编译
• #include < bits/stdc++.h> 在 C++ 中是如何工作的？

Quora不好的例子：

• 在编程竞赛中使用 #include < bits/stdc++.h> 而不是列出很多包含是好的做法吗？

为什么？因为它被当作 C++ 标准头文件使用，但没有标准提到它。因此，您的代码在构造上是不可移植的。你不会在 cppreference 上找到它的任何文档。所以它可能不存在。这是某人想象的虚构:)

我发现 - 令我震惊和难以置信 - 有一个著名的教程站点，每个 C++ 示例似乎都包含此标头。世界疯了。这就是证明。

---

致任何编写此类“教程”的人

请停止使用此标头。忘掉它。不要传播这种精神错乱。如果你不愿意理解为什么这样做是错误的，请相信我的话。我完全不能被当作权威人物对待，而且我可能有一半的时间都充满了它，但我只会在这一种情况下破例。我声称我知道我在这里说什么。相信我的话。我恳求你。

P.S. 我可以想象这个邪恶的想法可能发生的可恶的“教学标准”，以及导致它的情况。仅仅因为似乎有实际需要，并不能使它被接受——即使回想起来也是如此。

P.P.S. 不，没有实际需要。没有那么多 C++ 标准头文件，而且它们有很好的文档记录。如果你教书，你就会通过添加这样的“魔法”来伤害你的学生。培养具有神奇心态的程序员是我们最不想要的。如果您需要为学生提供 C++ 的子集以使他们的生活更轻松，只需制作一份讲义，其中包含适用于您教授的课程的简短标题列表，以及您希望学生使用的库结构的简明文档。

正如 @Lightness Races in Orbit 提到的 Quora 问题的最高答案中所解释的那样，在编程竞赛的背景下包括在内并没有错。可移植性、编译时间和标准化方面的缺点与此无关。如果示例代码使用 that，则在大学编程课程中也是如此。bits/stdc++.h

如果您正在编写生产代码，请不要使用它。根据您当前编写的代码的目的来回切换应该没什么大不了的。

有一个叫做Programming Puzzles & Code Golf的Stack Exchange网站。该网站上的编程谜题符合这个谜题的定义：

一种玩具、问题或其他设计，旨在通过提出需要通过独创性或耐心努力解决的困难来娱乐。

它们被设计为娱乐，而不是像一个在职的程序员可能会被日常工作中遇到的现实世界的问题逗乐一样。

Code Golf 是“一种休闲计算机编程竞赛，参赛者努力实现实现特定算法的最短源代码。在PP&CG网站上的答案中，你会看到人们在答案中指定了字节数。当他们找到一种方法来减少几个字节时，他们会删除原始数字并记录新数字。

正如你所料，代码高尔夫奖励极端的编程语言滥用。单字母变量名称。没有空格。创造性地使用库函数。未记录的功能。非标准编程实践。骇人听闻的黑客攻击。

如果程序员在工作中提交了包含高尔夫风格代码的拉取请求，它将被拒绝。他们的同事会嘲笑他们。他们的经理会顺便到他们的办公桌前聊天。即便如此，程序员还是通过向PP&CG提交答案来娱乐自己。

这与什么关系？正如其他人所指出的，使用它是懒惰的。它是不可移植的，所以你不知道它是否适用于你的编译器或你的编译器的下一个版本。它助长了坏习惯。它是非标准的，因此程序的行为可能与预期不同。它可能会增加编译时间和可执行文件的大小。stdc++.h

这些都是有效和正确的反对意见。那么为什么有人会使用这个怪物呢？

事实证明，有些人喜欢在没有代码高尔夫的情况下编程谜题。他们聚在一起参加 ACM-ICPC、Google Code Jam 和 Facebook Hacker Cup 等活动，或者在 Topcoder 和 Codeforces 等网站上竞争。他们的排名基于程序的正确性、执行速度以及他们提交解决方案的速度。为了最大限度地提高执行速度，许多参与者使用 C++。为了最大限度地提高编码速度，其中一些使用 .stdc++.h

这是个好主意吗？让我们检查一下缺点列表。可移植性？这并不重要，因为这些编码活动使用参赛者事先知道的特定编译器版本。是否符合标准？与使用寿命小于一小时的代码块无关。编译时间和可执行文件大小？这些不是比赛评分标准的一部分。

所以我们留下了坏习惯。这是一个有效的反对意见。通过使用此头文件，参赛者可以避免了解哪个标准头文件定义了他们在程序中使用的功能的机会。当他们编写真实世界的代码（而不是使用 ）时，他们将不得不花时间查找这些信息，这意味着他们的工作效率会降低。这就是练习的缺点。stdc++.hstdc++.h

这就提出了一个问题，如果竞争性编程鼓励使用和违反其他编码标准等坏习惯，为什么还值得参与。一个答案是，人们这样做的原因与他们在PP&CG上发布程序的原因相同：一些程序员发现在类似游戏的环境中使用他们的编码技能是令人愉快的。stdc++.h

因此，是否使用的问题归结为编程竞赛中编码速度的好处是否超过了使用它可能养成的坏习惯。stdc++.h

这个问题问：“为什么我不应该 #include？我意识到它被问到和回答是为了提出一个观点，而公认的答案旨在成为这个问题的唯一真实答案。但问题不在于“为什么我不应该在生产代码中 #include？因此，我认为考虑答案可能不同的其他情况是合理的。<bits/stdc++.h><bits/stdc++.h>

从 N4606，工作草案，编程语言 C++ 标准：

17.6.1.2 标头 [headers]

1. C++ 标准库的每个元素都在标头中声明或定义（根据需要）。

2. C++ 标准库提供了 61 个 C++ 库头文件，如表 14 所示。

表 14 — C++ 库头文件

<algorithm> <future> <numeric> <strstream>
<any> <initializer_list> <optional> <system_error>
<array> <iomanip> <ostream> <thread>
<atomic> <ios> <queue> <tuple>
<bitset> <iosfwd> <random> <type_traits>
<chrono> <iostream> <ratio> <typeindex>
<codecvt> <istream> <regex> <typeinfo>
<complex> <iterator> <scoped_allocator> <unordered_map>
<condition_variable> <limits> <set> <unordered_set>
<deque> <list> <shared_mutex> <utility>
<exception> <locale> <sstream> <valarray>
<execution> <map> <stack> <variant>
<filesystem> <memory> <stdexcept> <vector>
<forward_list> <memory_resorce> <streambuf>
<fstream> <mutex> <string>
<functional> <new> <string_view>

那里没有 <bits/stdc++.h>。这并不奇怪，因为<位/...>标头是实现细节，通常带有警告：

• 这是一个内部头文件，由其他库头文件包含。
• 不要尝试直接使用它。

<bits/stdc++.h> 还带有警告：

• 这是预编译标头的实现文件。

我们不使用的原因：

#include <bits/stdc++.h>

是因为效率。 让我打个比方： 对于那些了解 Java 的人： 如果你问你的教练以下是否是一个好主意，除非他们是一个糟糕的教练，否则他们会说不：

import java.*.*

#include...事情基本上做同样的事情......这不是不使用它的唯一原因，但它是不使用它的主要原因之一。 对于现实生活中的类比： 想象一下，你有一个图书馆，你想从图书馆借几本书，你会把整个图书馆搬到你家旁边吗？这将是昂贵和低效的。如果你只需要 5 本书，那么只需要拿出 5 本书......不是整个图书馆.....

#include <bits/stdc++.h>

看起来很方便，我只需要输入一个包含语句就可以了，它与移动整个图书馆是一样的，看我只需要移动一个完整的图书馆，而不是 5 本书，一本一本。对你来说看起来很方便，也就是说，对于真正必须搬家的人来说？？没有那么多，猜猜在 C++ 中移动的人会是你的电脑......计算机不会喜欢为您编写的每个源文件移动整个库:).....

我至少喜欢通过查看此头文件来查看可以包含的所有标头的列表，以及它们属于哪个版本的 C++。在这方面，它确实很有用。

包括，到底有多糟糕？<bits/stdc++.h>

我想看到一些真实的数据 - 一些数字来比较编译时间和二进制可执行文件的大小。所以，这里有一个快速的“hello world”比较测试。

注意：要了解头文件在哪里，以及其中有什么，请直接跳到底部标题为“在哪里和是什么？”的部分。<bits/stdc++.h><bits/stdc++.h>

总结：

包括 <bits/stdc++.h> “include all headers” 标头很容易，但编译速度相对较慢。

包含头文件适用于 GCC/g++ 编译器（大概也是 LLVM Clang 编译器，因为它们的目标是与 GCC 兼容），以及<bits/stdc++.h>

1. 对二进制可执行文件大小没有区别，但
2. 编译时间最多可延长 4 倍！

我的测试

下面是一个示例 C++ 程序：

include_bits_stdc++.cpp：

// We will test including this header vs NOT including this header
#include <bits/stdc++.h>

#include <iostream>  // For `std::cin`, `std::cout`, `std::endl`, etc.

int main()
{
    printf("Hello ");
    std::cout << "world!\n\n";

    return 0;
}

下面是一些生成和运行命令：

# make a bin directory
mkdir -p bin

# compile, timing how long it takes
time g++ -Wall -Wextra -Werror -O3 -std=c++17 include_bits_stdc++.cpp -o bin/a

# check binary executable size
size bin/a

# run
bin/a

顶部没有#include <bits/stdc++.h>

如果我按原样运行上面的“编译”命令，我会看到以下 10 个编译时间：

real    0m0.362s
real    0m0.372s
real    0m0.502s
real    0m0.383s
real    0m0.367s
real    0m0.283s
real    0m0.294s
real    0m0.281s
real    0m0.292s
real    0m0.276s

平均编译时间：= 0.3412 秒。(0.362 + 0.372 + 0.502 + 0.383 + 0.367 + 0.283 + 0.294 + 0.281 + 0.292 + 0.276)/10

size bin/a显示：

text    data     bss     dec     hex filename
2142     656     280    3078     c06 bin/a

WITH在顶部#include <bits/stdc++.h>

10 次编译：

real    0m1.398s
real    0m1.006s
real    0m0.952s
real    0m1.331s
real    0m1.549s
real    0m1.454s
real    0m1.417s
real    0m1.541s
real    0m1.546s
real    0m1.558s

平均编译时间：= 1.3752 秒。(1.398 + 1.006 + 0.952 + 1.331 + 1.549 + 1.454 + 1.417 + 1.541 + 1.546 + 1.558)/10

size bin/a显示：

text    data     bss     dec     hex filename
2142     656     280    3078     c06 bin/a

结论

因此，包含标头与 gcc/g++ 编译器配合良好，并且对二进制可执行文件大小没有影响，但编译需要 1.3752 秒 / 0.3412 秒 = 4 倍的时间！

在哪里，什么是？<bits/stdc++.h>

总结

头文件作为 gcc/g++ 编译器的一部分包含在内。<bits/stdc++.h>

如果在 Linux 上，它将位于本地系统上的 。/usr/include/x86_64-linux-gnu/c++/8/bits/stdc++.h

您可以在此处直接在线查看 gcc 源代码中的文件：gcc/libstdc++-v3/include/precompiled/stdc++.h

我至少喜欢通过查看该头文件来查看可以包含的所有标头的列表，以及它们属于哪个版本的 C++。在这方面，它确实很有用。

详

如果你在一个IDE中打开上面的代码，有一个很棒的索引器，比如Eclipse（它有我见过的最好的索引器;它的索引比MS VSCode好得多），并且+在行上，它将直接跳转到你系统上的头文件！在 Linux Ubuntu 上，它会直接跳转到此路径并打开此文件：.CtrlClick#include <bits/stdc++.h>/usr/include/x86_64-linux-gnu/c++/8/bits/stdc++.h

您可以直接在 gcc 源代码中查看此文件的最新版本，地址为：gcc/libstdc++-v3/include/precompiled/stdc++.h。它只是一个包含所有其他头文件的头文件！这非常有用且很有见地，只需在一个地方查看所有头文件即可了解它们是什么以及它们包含什么！同样，在 Eclipse 中，您可以轻松地对每个包含的头文件进行 + 操作，以直接跳转到其源代码实现。CtrlClick

以下是 gcc 编译器中包含的完整、最新的头文件。如果您想将此内容包含在您自己的个人项目中或与其他编译器一起使用，您可以随时复制和粘贴此内容并自行创建此文件。<bits/stdc++.h>

gcc/libstdc++-v3/include/precompiled/stdc++.h：

// C++ includes used for precompiling -*- C++ -*-

// Copyright (C) 2003-2022 Free Software Foundation, Inc.
//
// This file is part of the GNU ISO C++ Library.  This library is free
// software; you can redistribute it and/or modify it under the
// terms of the GNU General Public License as published by the
// Free Software Foundation; either version 3, or (at your option)
// any later version.

// This library is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
// GNU General Public License for more details.

// Under Section 7 of GPL version 3, you are granted additional
// permissions described in the GCC Runtime Library Exception, version
// 3.1, as published by the Free Software Foundation.

// You should have received a copy of the GNU General Public License and
// a copy of the GCC Runtime Library Exception along with this program;
// see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
// <http://www.gnu.org/licenses/>.

/** @file stdc++.h
 *  This is an implementation file for a precompiled header.
 */

// 17.4.1.2 Headers

// C
#ifndef _GLIBCXX_NO_ASSERT
#include <cassert>
#endif
#include <cctype>
#include <cerrno>
#include <cfloat>
#include <ciso646>
#include <climits>
#include <clocale>
#include <cmath>
#include <csetjmp>
#include <csignal>
#include <cstdarg>
#include <cstddef>
#include <cstdio>
#include <cstdlib>
#include <cstring>
#include <ctime>
#include <cwchar>
#include <cwctype>

#if __cplusplus >= 201103L
#include <ccomplex>
#include <cfenv>
#include <cinttypes>
#include <cstdalign>
#include <cstdbool>
#include <cstdint>
#include <ctgmath>
#include <cuchar>
#endif

// C++
#include <algorithm>
#include <bitset>
#include <complex>
#include <deque>
#include <exception>
#include <fstream>
#include <functional>
#include <iomanip>
#include <ios>
#include <iosfwd>
#include <iostream>
#include <istream>
#include <iterator>
#include <limits>
#include <list>
#include <locale>
#include <map>
#include <memory>
#include <new>
#include <numeric>
#include <ostream>
#include <queue>
#include <set>
#include <sstream>
#include <stack>
#include <stdexcept>
#include <streambuf>
#include <string>
#include <typeinfo>
#include <utility>
#include <valarray>
#include <vector>

#if __cplusplus >= 201103L
#include <array>
#include <atomic>
#include <chrono>
#include <codecvt>
#include <condition_variable>
#include <forward_list>
#include <future>
#include <initializer_list>
#include <mutex>
#include <random>
#include <ratio>
#include <regex>
#include <scoped_allocator>
#include <system_error>
#include <thread>
#include <tuple>
#include <typeindex>
#include <type_traits>
#include <unordered_map>
#include <unordered_set>
#endif

#if __cplusplus >= 201402L
#include <shared_mutex>
#endif

#if __cplusplus >= 201703L
#include <any>
#include <charconv>
// #include <execution>
#include <filesystem>
#include <optional>
#include <memory_resource>
#include <string_view>
#include <variant>
#endif

#if __cplusplus >= 202002L
#include <barrier>
#include <bit>
#include <compare>
#include <concepts>
#if __cpp_impl_coroutine
# include <coroutine>
#endif
#include <latch>
#include <numbers>
#include <ranges>
#include <span>
#include <stop_token>
#include <semaphore>
#include <source_location>
#include <syncstream>
#include <version>
#endif

#if __cplusplus > 202002L
#include <expected>
#include <spanstream>
#if __has_include(<stacktrace>)
# include <stacktrace>
#endif
#include <stdatomic.h>
#endif

另请参阅

1. https://www.geeksforgeeks.org/bitsstdc-h-c/
   • 不过，这篇文章抄袭了 Stack Overflow;在这里看到我的评论： #include < bits/stdc++.h> 在 C++ 中是如何工作的？
2. [我的问题和答案] 了解输出中的 、 、 和 的含义：textdatabssdecsize
   1. 电气工程堆栈交换：如何在编译时知道STM32的闪存和动态存储器（SRAM）用完了多少？
   2. 将 binutils 大小输出从“sysv”格式 （size --format=sysv my_executable） 转换为 “berkeley” 格式 （size --format=berkeley my_executable）

对我来说，最大的问题是包含此头文件不会编译。因此，如果它在那里，我将不得不删除它，尝试编译并添加所需的标准头文件。

如果你的老师是ICPC教练，那么他/她是对的，但如果你的老师是软件工程师，他/她可能不是。

两者都有利有弊：

优点：

• 使用它可以节省编码时间
• 您无需为记住哪个标头包含什么而感到痛苦
• 如果你有一个源代码限制（ICPC风格比赛通常有），并且你想挤进尽可能多的行，那么它可能会派上用场。

缺点：

• 但它会增加编译时间。
• 由于它包含许多命名空间，因此您可能会意外遇到可能难以调试的问题。