Почему мне не следует #include ‹bits / stdc ++. H›?

Включение <bits/stdc++.h> становится все более распространенным явлением в Stack Overflow, возможно, что-то новое, добавленное в национальную учебную программу в текущем учебном году.

Я полагаю, что преимущества смутно описаны таким образом:

• Вам нужно написать только одну #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 ++, чтобы облегчить их жизнь, просто подготовьте раздаточный материал с кратким списком заголовков, применимых к курсу, который вы преподаете, и с краткой документацией по конструкциям библиотеки, которые, как вы ожидаете, студенты будут использовать.

Есть сайт Stack Exchange под названием Программирование головоломок и кодового гольфа. Головоломки программирования на этом сайте соответствуют этому определению головоломки:

игрушка, проблема или другое приспособление, предназначенное для развлечения, представляя трудности, которые нужно решить изобретением или терпеливыми усилиями.

Они созданы для развлечения, а не для того, чтобы работающий программист мог развлечься реальной проблемой, с которой он сталкивается в своей повседневной работе.

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 <bits/stdc++.h>?» Я понимаю, что этот вопрос был задан, и на него был дан ответ, и принятый ответ призван стать Единым Истинным Ответом на этот вопрос. Но вопрос не в том, почему я не должен # включать <bits/stdc++.h> в производственный код? Поэтому я считаю разумным рассмотреть другие сценарии, в которых ответ может быть другим.

Из N4606, Рабочий проект, Стандарт языка программирования C ++:

17.6.1.2 Заголовки [заголовки]

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 / ...› представляют собой детали реализации и обычно содержат предупреждение:

*  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.

Причина, по которой мы не используем:

#include <bits/stdc++.h>

это из-за эффективности. Позвольте мне провести аналогию: для тех из вас, кто знает Java: если вы спросите своего инструктора, было ли это хорошей идеей, они бы отказались, если только он не плохой инструктор:

import java.*.*

Элемент #include ... в основном делает то же самое ... Это не единственная причина не использовать его, но это одна из основных причин не использовать его. Для аналогии из реальной жизни: представьте, что у вас есть библиотека, и вы хотите взять в библиотеке пару книг. Не могли бы вы переместить всю библиотеку рядом с вашим домом? Это было бы дорого и неэффективно. Если тебе нужно всего 5 книг, то возьми только 5 ... Не всю библиотеку ...

#include <bits/stdc++.h>

Выглядит удобно для программы. Мне нужно ввести только один оператор include, и он работает, то же самое с перемещением всей библиотеки, послушайте, мне нужно перемещать только одну целую библиотеку вместо 5 книг, одну за другой. Выглядит удобно для вас, то есть для человека, который действительно должен делать переезд ?? Не так уж и много, и угадайте, что в C ++ человек, выполняющий перемещение, будет вашим компьютером ... Компьютеру не понравится перемещать всю библиотеку для каждого исходного файла, который вы пишете :) .....