Почему стандартная библиотека С++ разделена на несколько компонентов/библиотек?

Стандарт C++ делит стандартную библиотеку на разные отдельные компоненты/библиотеки. Некоторые компоненты состоят из нескольких заголовков.

Почему стандарт организован таким образом? Какую практическую пользу это нам дает? Почему стандартная библиотека не определяет только заголовки (+ потенциально реализации)?

Я предполагаю, что эта информация может быть даже несколько важна для C++ Dev, а не для члена комитета/поставщика компилятора, поскольку cppreference, например, часто указывает, из какой библиотеки берется данный заголовок:

Этот заголовок является частью общей служебной библиотеки.

Смотрите здесь, например. Верно ли это предположение? Если да, то когда?

Вместо того, чтобы валить все в одну корзину, как это делает PHP? Даже C разбивает их на отдельные заголовочные файлы.

tadman 21.11.2022 01:09

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

Sam Varshavchik 21.11.2022 01:10

@tadman Если вы определяете, что некоторые вещи должны идти в заголовок A, а другие - в заголовок B, то у вас также нет этой проблемы с скоплением.

Brotcrunsher 21.11.2022 01:10

Я не уверен, что вы имеете в виду. С++ довольно хорошо организован, учитывая, что много внимания было уделено разделению задач . Хотя C++ не так сильно ориентируется на шаблоны проектирования, как некоторые другие языки, он пытается придерживаться организационной философии, которая развивалась вместе с самой стандартной библиотекой.

tadman 21.11.2022 01:11

@SamVarshavchik Технические характеристики не новы. У вас уже есть организация, когда вы определяете, что идет к какому заголовку.

Brotcrunsher 21.11.2022 01:11

«Если вы определяете, что некоторые элементы должны быть помещены в заголовок А, а другие — в заголовок Б» — вы нажимали на какие-либо ссылки в этом черновике? Он четко говорит вам, какие заголовки принадлежат какой библиотеке, и вы можете дополнительно просмотреть краткий обзор каждого заголовка, чтобы увидеть, что именно должен иметь каждый заголовок.

Ranoiaetep 21.11.2022 01:12

@Ranoiaetep Боюсь, вы можете упустить мою мысль. Мой вопрос в том, почему мы группируем эти заголовки в библиотеки. Разделение задач, организации и т. д. уже достигнуто с помощью определений заголовков.

Brotcrunsher 21.11.2022 01:15

@Brotcrunsher Нет разных библиотек в смысле, например. .so/.dll файлы. Стандарт указывает только, какие заголовки содержат какие объявления (как минимум). Он ничего не указывает на организацию определений. Обычно существует только одна библиотека в смысле одного .so/.dll. Но их также может быть много или ни одного (они могут быть внутренними для компилятора). Слово «библиотека» используется только в организационных целях внутри стандарта.

user17732522 21.11.2022 01:19

@user17732522 user17732522 Я понял. У меня вопрос, зачем нужна эта организация, если заголовки уже дают нам форму организации.

Brotcrunsher 21.11.2022 01:20

@Brotcrunsher Итак, вы хотите иметь раздел для каждого заголовочного файла в стандарте вместо текущих разделов «библиотеки»?

user17732522 21.11.2022 01:22

@ user17732522 Я не предлагаю никаких изменений в стандарте. Я просто хочу понять, почему была сделана эта (для меня в настоящее время кажущаяся произвольной) группировка. Какая нам от этого выгода? например, ссылается ли стандарт на какую-либо библиотеку, кроме определения самого себя или перечисления всех библиотек? И почему cppreference и другие сайты вообще упоминают библиотеку?

Brotcrunsher 21.11.2022 01:25

@Brotcrunsher: «Мой вопрос в том, почему эта организация требуется» «Требуется» кем?

Nicol Bolas 21.11.2022 01:27

@NicolBolas Ну, если это определяет сам стандарт, то я полагаю, что он должен служить какой-то цели. Какая это цель? Этого у нас еще нет, определив заголовки.

Brotcrunsher 21.11.2022 01:28

«кажущаяся произвольной группировка» — если вы просто смотрите на общую служебную библиотеку, она будет выглядеть произвольно, поэтому она и называется общей. Большинство других библиотек имеют гораздо более четкую тему.

Ranoiaetep 21.11.2022 01:29

@Brotcrunsher: Что вы подразумеваете под «определяет это»? Ничего не определено в том, что касается поведения C++. Вы говорите о названии глав в стандарте. У него нет никакого внутреннего значения, кроме того, что слова говорят о том, что они означают.

Nicol Bolas 21.11.2022 01:29

Это в значительной степени чисто для организации стандартного документа в удобочитаемом виде. Вы можете найти обсуждение конкретных вариантов в редакционных выпусках, таких как github.com/cplusplus/draft/issues/5124.

user17732522 21.11.2022 01:33

Цель этого та же самая, почему любые руководства делят разные части на разделы. Скажем, это руководство по эксплуатации автомобиля, каждая отдельная часть автомобиля имеет свое назначение, и вы можете просто посвятить каждый раздел определенной детали, не группируя их вместе. Тем не менее, мы сгруппировали все индикаторы приборной панели в один и тот же раздел, чтобы читателю было легче найти информацию, не зная точной информации, которую он ищет.

Ranoiaetep 21.11.2022 01:36

Большинству приложений не требуется вся библиотека, поэтому ее включение потребует много времени на компиляцию. Особенно на медленных машинах.

Neil 21.11.2022 01:36

@NicolBolas Это хороший момент. Думаю, меня в основном смущает, почему эта информация присутствует на cppreference. Это всегда казалось мне шумом, я не вижу, кому это помогает.

Brotcrunsher 21.11.2022 01:37

У вас также есть заголовки, перечисленные в алфавитном порядке eel.is/c++draft/headers Там тоже нет конкретного значения.

BoP 21.11.2022 01:39

Точно так же, группируя различные заголовки в единую библиотеку, это дает читателям быстрый способ узнать, что доступно. Когда люди из другого мира видят <list>, им может быть трудно представить, что были также <array> и <vector>. Сгруппировав их вместе, вы можете легко найти все доступные контейнеры.

Ranoiaetep 21.11.2022 01:41
[JS за 1 час] - 9. Асинхронный
[JS за 1 час] - 9. Асинхронный
JavaScript является однопоточным, то есть он может обрабатывать только одну задачу за раз. Для обработки длительных задач, таких как сетевые запросы,...
Топ-10 компаний-разработчиков PHP
Топ-10 компаний-разработчиков PHP
Если вы ищете надежных разработчиков PHP рядом с вами, вот список лучших компаний по разработке PHP.
Скраппинг поиска Apple App Store с помощью Python
Скраппинг поиска Apple App Store с помощью Python
📌Примечание: В этой статье я покажу вам, как скрапировать поиск Apple App Store и получить точно такой же результат, как на Apple iMac, потому что...
Редкие достижения на Github ✨
Редкие достижения на Github ✨
Редкая коллекция доступна в профиле на GitHub ✨
Подъем в javascript
Подъем в javascript
Hoisting - это поведение в JavaScript, при котором переменные и объявления функций автоматически "перемещаются" в верхнюю часть соответствующих...
Улучшение генерации файлов Angular
Улучшение генерации файлов Angular
Angular - это фреймворк. Вы можете создать практически любое приложение без использования сторонних библиотек.
1
21
69
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий
Разделение задач, организации и т. д. уже достигнуто с помощью определений заголовков.

Они?

Рассмотрим Глава 22: Утилиты. Эта глава охватывает материал, определенный в 13 отдельных заголовках. Стандарт мог бы состоять из 13 отдельных глав, но... почему? Что в этом хорошего? Есть ли какая-то причина помещать все это в отдельные главы, когда они будут намного короче, чем большинство других глав?

Рассмотрим Главу 31: Ввод/вывод. В этой главе рассматриваются вещи, определенные в 14 отдельных заголовках. Но материалы в этих заголовках часто тесно связаны друг с другом. Все потоки в конечном итоге построены на базовых классах iostream. Некоторые из них ссылаются на вещи в других заголовках, например, на возможность файловых потоков использовать объекты filesystem::path.

Но все они в конечном счете связаны с вводом/выводом. Поэтому имеет смысл объединить их все в одну главу.

У них могло бы быть 14 отдельных глав, по одной на каждый заголовок, но в этом не было бы никакой пользы. Действительно, теперь вам некуда было бы поместить раздел требований iostreams, который вообще не привязан ни к какому заголовку.

Говоря о важной информации, которая не привязана к заголовку, одним из самых важных разделов в главе «Контейнер» является раздел Требования, который применяется к каждому контейнеру. Этот раздел абсолютно необходим для понимания всего, что происходит в любой документации контейнера, и во многих случаях определяет поведение нескольких функций, определения которых не перечислены в разделе для этих отдельных заголовков. Это связано с тем, что эти функции ведут себя одинаково для всех контейнеров.

Я имею в виду, действительно ли нам нужно видеть девять отдельных повторений определений для begin, end и т. д.? Весь смысл контейнеров в том, чтобы иметь единый интерфейс, чтобы вы могли легко понять, как все работает. И если вы собираетесь иметь единый интерфейс, повторять определение этого интерфейса довольно бессмысленно.

А еще есть места, где стандарт может просто указать прямо на главу и сказать: «Все эти вещи также обладают этим свойством». Наиболее важной из них является концепция автономных реализаций. Автономные реализации — это реализации C++, которые не хотят реализовывать всю стандартную библиотеку, потому что в ней есть много вещей, которые на самом деле не нужны их клиентам (например, микроконтроллеры не заботятся о файловых системах). Но есть части стандартной библиотеки, которые должны быть реализованы даже в этих системах.

Это было более заметно в стандартах до C++23, но во многих случаях в стандарте просто говорилось: «все в этой главе/разделе должно быть самостоятельным». Это намного проще сделать, когда глава/раздел может содержать столько заголовков, сколько имеет смысл.

Вероятно, это одна из причин, по которой глава Atomic не является частью главы Threading (опять же, до C++23).

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

Другие вопросы по теме