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

Question

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

c++portabilityturbo-c++c++-faqimplementation-defined-behavior

449

我发布了一个带有代码的问题，其中唯一的#include指令如下：

#include <bits/stdc++.h>

我的老师让我做这个，但在评论区有人告诉我不应该这样做。

为什么？

- Lightness Races in Orbit

155

哦，我应该知道 using namespace std; 也有一个 include 版本存在。 - user4581301

7

为什么这个头文件会存在呢？肯定没有任何标准库包含它，因为那会带来很多无用的东西。如果它不被任何公共库包含...那么为什么会在发布版中被包含呢？ - Chris Beck

20

@ChrisBeck：这是一个实现细节。它不是“公共API”的一部分，也不是为了使用而设计的。但是必须将其发送，否则什么都无法工作。标准库可能不会单独使用它，但它可用于预编译头文件中。请参阅顶部的注释，其中写着：“这是用于预编译头文件的实现文件。” - Lightness Races in Orbit

5

“不是公共API的一部分，也不是供使用的。”这完全是错误的，它旨在供公众使用，作为一个预编译头文件。Libstdc++会(预)编译并安装该头文件的预编译版本，因此如果您包含它，那么G++实际上将包括bits/stdc++.h.gch，即预编译版本。它存在的原因是必须存在，以便可以生成它的预编译版本。 - Jonathan Wakely

8

我指的是标准库的公共API，而不是libstdc++的API。每天在Stack Overflow和项目中使用它的人并不是出于你所说的原因或用例。当然，我的评论可能可以措辞得更准确，但请注意我确实指出了它在预编译头文件中的用途。欢迎写一个竞争性答案。 - Lightness Races in Orbit

显示剩余6条评论

9个回答

118

为什么？因为它的使用方式好像是应该作为C++标准头文件的，但是没有标准提到它。因此你的代码在构建时就非可移植的。你在cppreference上找不到任何关于它的文档。所以它可能不存在。这只是某个人想象出来的东西 :)

我发现一个众所周知的教程网站每个C++示例都似乎包含了这个头文件，令我感到恐惧和不信。世界疯了。这就是证明。

对于写这种“教程”的人

请停止使用这个头文件。忘记它。不要传播这种疯狂的行为。如果您不愿意理解为什么这样做是错误的，请相信我的话。我不希望被当作任何事情的权威人士，而且我可能有一半的时间都是胡说八道，但我只在这一个特殊情况下例外。我声称我知道我在这里在谈论些什么。相信我。我恳求你。

P.S. 我可以很好地想象出这种邪恶想法可能已经发生在哪种可怕的“教学标准”中，以及导致这种情况的情况。只是因为似乎存在实际需要并不意味着它是可以接受的——即使是回顾也不行。

P.P.S. 不，没有实际需要。C++标准头文件并不是很多，而且它们都有良好的文档。如果您作为教师，通过添加这样的“魔法”来帮助学生，那么您将给他们造成不便。我们最不想要的就是培养出一群神奇思维的程序员。如果您需要为学生提供C++的子集以方便他们的学习，请提供一个手册，包含适用于所教授课程的少量头文件，并提供对您期望学生使用的库构造的简明文档。

- Kuba hasn't forgotten Monica

5

那个众所周知的网站就是那个每个 C++ 示例看起来都像 C 程序的网站吗？ - Surt

8

他在谈论GeeksForGeeks。 - SuperNoob

10

当包含using namespace std;以及相应的头文件时，像用户自定义的gcd、swap或名为data的变量等简单事物将会表现出奇怪的行为或者根本无法编译，这会让编码者不知所措。 - PaulMcKenzie

8

我在谈论那些典型的“众所周知的网站”。不幸的是，它们有很多。而且它们看起来总是像盲人引导盲人一样 :( - Kuba hasn't forgotten Monica

85

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

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

它们的目的是为了娱乐，而不是像工作中遇到的现实问题那样让程序员感到愉悦。 Code Golf是“一种娱乐性的计算机编程竞赛，参与者努力实现一定算法的最短源代码”。在PP&CG网站的答案中，您会看到人们指定答案中的字节数。当他们找到缩减几个字节的方法时，他们会划掉原始数字并记录新数字。

正如您所预期的那样，代码高尔夫奖励极端的编程语言滥用。单个字母的变量名。没有空格。创造性地使用库函数。未记录的特性。非标准的编程实践。令人震惊的黑客技术。

如果程序员提交了类似高尔夫风格的代码拉取请求，则会被拒绝。他们的同事会嘲笑他们。他们的经理会过来和他们聊聊。即便如此，程序员仍会通过提交答案到PP&CG来娱乐自己。

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

这些都是合理且正确的反对意见。那么为什么会有人使用这种可怕的东西呢？

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

这是个好主意吗？让我们检查一下缺点清单。可移植性？由于这些编程活动使用参赛者事先知道的特定编译器版本，所以这并不重要。符合标准？对于使用寿命少于一小时的代码块来说，这并不相关。编译时间和可执行文件大小？这些不是比赛评分标准的一部分。

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

这引出了一个问题，为什么值得参加竞争性编程，如果它鼓励像使用stdc++.h和违反其他编码标准这样的坏习惯。其中一个答案是，人们之所以这样做，是因为他们与在PP&CG上发布程序的原因相同：一些程序员发现在类似游戏的情境中使用他们的编码技能很有趣。

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

这个问题问：“为什么我不应该#include ？” 我意识到这个问题是为了说明一个观点而提出并回答的，而被接受的答案旨在成为这个问题的唯一正确答案。但是这个问题并不是“为什么我不应该在生产代码中#include ？”因此，我认为考虑其他可能不同的情况是合理的。

- RedGreenCode

15

我已经点赞了，但值得指出的是，“为了好玩”是参加竞技编程的好理由。另一方面，“为了给潜在雇主留下印象”不是好理由——这会对我产生负面影响。 - Martin Bonner supports Monica

10

我知道一些招聘经理认为竞赛式编程经验是个警示信号。但只要顶尖的软件公司在面试中使用类似竞赛编程的问题，并且组织编程比赛来寻找新员工，那么竞赛式编程将会在有抱负的开发者中流行。 - RedGreenCode

11

如果你们公司的技术面试官在面试中使用算法谜题（许多公司都这样做），那么有竞争编程经验的候选人就会有优势。也许对于候选人来说，明智之举是参加竞争编程，但避免在简历中提及。 - RedGreenCode

8

虽然这个头文件确实可以在某些竞赛编程中使用，但它并不是它的来源。它来自于一个课堂。而教授那个课堂的人有足够的影响力通过随之而来的级联作用污染了数万甚至数十万的学生（通过教育老师和同龄人，他们无意中传播了这种病毒）。现在这些学生也在撰写教程，成为教程的首选地点。我只想蜷缩在角落里哭泣。竞赛编程网站应该只有一个正则表达式来拒绝任何非标准头文件。 - Kuba hasn't forgotten Monica

7

@MartinBonnersupportsMonica 提到编程问题（CP）在简历上，可以展示相关的解决问题技能和积极热情，这种提法被视为负面是完全不可理喻的。编程风格、良好的架构使用、团队合作等都是必要的，但申请人不必在每个简历项目上都勾选所有这些项目。 - Elliott

显示剩余7条评论

27

来自C++编程语言的标准草案N4606：

17.6.1.2 头文件[headers]

每个C++标准库元素在头文件中声明或定义（如果适用）。
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/...> 标头是实现细节，通常会带有警告：

*  This is an internal header file, included by other library headers.
*  Do not attempt to use it directly.

<bits/stdc++.h>同样会发出警告：

*  This is an implementation file for a precompiled header.

- Bulletmagnet

8

我至少喜欢看到一个可以包含的所有标题列表，并查看此头文件所涉及的C++版本。在这方面，它真的非常有用。 < h2 > 包括 < code ><bits/stdc++.h>，真的很糟糕吗？

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

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

摘要：

包含<bits/stdc++.h>“包含所有头文件”的头文件很容易，但相对编译速度较慢。

包含头文件<bits/stdc++.h>在gcc/g++编译器（以及可能的llvm clang编译器，因为它们旨在与gcc兼容）上可以正常工作，并且：

对二进制可执行文件大小没有影响，
但是编译速度最多需要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 dir
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.362 + 0.372 + 0.502 + 0.383 + 0.367 + 0.283 + 0.294 + 0.281 + 0.292 + 0.276)/10 = 0.3412 秒.

size bin/a 显示：

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

在顶部加入`#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.398 + 1.006 + 0.952 + 1.331 + 1.549 + 1.454 + 1.417 + 1.541 + 1.546 + 1.558)/10 = 1.3752 秒。 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>`是什么？在哪里？

摘要

<bits/stdc++.h>头文件是gcc/g++编译器的一部分。

如果在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 好得多）中打开上面的代码，并在#include <bits/stdc++.h>行上按下 Ctrl + Click，它将直接跳转到系统上的头文件！在 Linux Ubuntu 上，它将直接跳转到此路径并打开此文件：/usr/include/x86_64-linux-gnu/c++/8/bits/stdc++.h。

你可以直接在gcc源代码中查看此文件的最新版本，链接如下：gcc/libstdc++-v3/include/precompiled/stdc++.h。这只是一个头文件，包含了所有其他头文件！这真的很有用和有见地，只需在一个地方查看所有头文件，就能对它们以及它们所包含的东西有一个基本的了解！而且，在Eclipse中，你可以轻松地通过Ctrl+Click跳转到每个被包含头文件的源代码实现。

这里是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

参见

https://www.geeksforgeeks.org/bitsstdc-h-c/
- 这篇文章剽窃了Stack Overflow上的内容，可以看看我在这里的评论：《#include在C++中是如何工作的？》
[我的问题和答案] 学习在size输出中text、data、bss和dec的含义：
1. Electrical Engineering Stack Exchange: 如何在编译时找出使用了多少STM32的Flash内存和动态内存（SRAM）？
2. 将binutils size输出从“sysv”格式（size --format=sysv my_executable）转换为“berkeley”格式（size --format=berkeley my_executable）

- Gabriel Staples

2

由于该文件是GPL许可的，你在复制它用于自己的项目时应该小心。这可能会给你和你的雇主带来非常不幸的法律责任。 - undefined

7

我们不使用的原因：

#include <bits/stdc++.h>

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

import java.*.*

#include指令基本上也是做同样的事情...这不是不使用它的唯一原因，但确实是不使用它的主要原因之一。

一个现实生活中的类比：想象一下你有一个图书馆，并且想从图书馆借几本书，你会把整个图书馆搬到你家旁边吗？这将是昂贵和低效的。如果你只需要5本书，那么就只拿出5本...而不是整个图书馆.....

#include <bits/stdc++.h>

看起来很方便，只需键入一个包含语句就可以工作了，移动整个库也是一样，只需要移动整个库而不是逐个移动五本书。对于你来说似乎很方便，但对于实际需要搬运的人来说呢？并不是那么方便，而且猜猜在C++中负责搬运的人将会是您的计算机......计算机并不喜欢为您编写的每个源文件搬移整个库：)

- Yunfei Chen

2

这几乎可以肯定是为什么没有人认真提出“包含所有内容”的标准头文件的根本原因。因此，有一个合理的主张称其为我们不使用它的"_原因_”。 - Toby Speight

如果我没有一个大型项目，我能使用bits/stdc++.h吗？ - UNREAL

@UNREAL 我的经验是，如果没有正确设置预编译头文件，包含bits/stdc++.h会使编译时间增加近一个数量级（更好的磁盘IO和没有杀毒软件将在这里有很大帮助）。因此，如果单个小文件的构建时间从半秒钟增加到五秒钟，你可能会在大约3次编译中超过通过输入四个或五个头文件而节省的时间。换句话说，如果你的程序第一次或第二次就能正常工作，那么你就赢了。之后你就开始输了。 - user4581301

没错，IDE就是我们的天使，毫无烦恼。 - UNREAL

1

比较非常错误，答案也是错误的：在Java中，import java.*.*是有效且定义良好的，在C++中，#include <bits/stdc++.h>不是，因为该头文件甚至说明了它是GCC的内部头文件和实现细节。它随时可能会更改，可能包含使您的代码格式化驱动器的宏，也可能在下一个版本中消失。 - ABaumstumpf

显示剩余4条评论

2

如果你的老师是一个ICPC教练，那他/她是正确的；但如果你的老师是一位软件工程师，可能他/她就不对了。

两者都有利弊：

利：

使用它可以节省编码时间
你不需要费力记住哪个头文件包含了什么
如果你受到源代码限制（通常在ICPC风格的比赛中），并且想要尽可能多地挤入行数，这可能会派上用场。

弊：

但它会增加编译时间。
由于它包含了许多命名空间，你可能会无意中遇到难以调试的问题。

- ishandutta2007

1

如@Lightness Races in Orbit提到的Quora问题的顶部答案所解释的那样，在编程竞赛的情境下包含bits/stdc++.h没有任何问题。在那里，与可移植性、编译时间和标准化相关的缺点并不重要。如果示例代码使用该包含，则在大学编程课程中也是如此。

如果你正在编写生产代码，则不要使用它。根据你当前编写的代码的目的轻松切换回去和切换回来不应该是什么大问题。

- RedGreenCode

37

如果一场编程比赛的评判标准是破损的、非标准的代码，那么我真的不明白它的意义所在。“谁能最快地写出最糟糕的代码”太棒了！好吧，恭喜你…… - Lightness Races in Orbit

14

使用短变量名和使用#include <bits/stdc++.h>是完全不同的事情！ - Lightness Races in Orbit

30

如果在大学编程课上使用了包含某代码文件的示例代码，情况也是如此。天哪，教授所教的人并不知道更好的方法。他们不知道什么是合适的，什么是不合适的：教授写的任何东西都被视为信仰圣典。请不要让任何教育工作者认为这种愚蠢是合理的。 - Kuba hasn't forgotten Monica

16

“Broken”、“non-standard”、“non-portable”、“idiocy”这些都是无关紧要的恐吓词语，不应该在此讨论中出现。使用所讨论的include的代码并不比包含第三方库的代码更加不可移植。如果需要，在必要时，它是可以轻松移植的，绝对是无害的。我认为，将使用该include的成千上万个程序称为“broken”是毫无必要的挑衅行为。这次讨论是一个很好的例子，说明了当标准主义和可移植性狂热妨碍了方便性时会发生什么。 - Evgeni Sergeev

12

安装第三方库以满足依赖关系和必须大力修改别人的代码使其正常运行之间有很大的区别（因此必然会在过程中创建分支）。你指责我们除了使用“恐吓性词语”外什么都没做，但我要求你解释一下你为什么在这里说我们是“迂腐之徒”和“狂热者”，并且没有进一步的目标。医生，请先治愈你自己。 - Lightness Races in Orbit

显示剩余13条评论

0

对我来说最大的问题是包含这个头文件无法编译。因此，如果它存在，我就必须删除它，尝试编译，并添加所需的标准头文件。

- gnasher729

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Lightness Races in Orbit · Accepted Answer

包括<bits/stdc++.h>似乎越来越常见于Stack Overflow，可能是当前学年的国家课程中新添加的内容。

我想，其优点大致如下：

您只需要编写一行#include。
您不需要查找每个标准头文件所在的位置。

不幸的是，这是一种懒惰的方法，直接命名GCC内部头文件而不是像<string>、<iostream>和<vector>等单独的标准头文件。它破坏了可移植性并培养了糟糕的习惯。

缺点包括：

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

不要这样做！

更多信息：

Quora不好的一个例子：

在编程竞赛中使用 #include <bits/stdc++.h> 而不是列出许多包含文件，这样做是否是良好的实践？

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

摘要：

我的测试

不使用顶部的 #include <bits/stdc++.h>

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

结论

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

摘要

详情

参见

不使用顶部的 `#include <bits/stdc++.h>`

在顶部加入`#include <bits/stdc++.h>`

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