Почему стандартная библиотека С++ разделена на несколько компонентов/библиотек?
Стандарт C++ делит стандартную библиотеку на разные отдельные компоненты/библиотеки. Некоторые компоненты состоят из нескольких заголовков.
Почему стандарт организован таким образом? Какую практическую пользу это нам дает? Почему стандартная библиотека не определяет только заголовки (+ потенциально реализации)?
Я предполагаю, что эта информация может быть даже несколько важна для C++ Dev, а не для члена комитета/поставщика компилятора, поскольку cppreference, например, часто указывает, из какой библиотеки берется данный заголовок:
Этот заголовок является частью общей служебной библиотеки.
Смотрите здесь, например. Верно ли это предположение? Если да, то когда?
По той же причине романы делятся на главы, а не на один сплошной кусок текста, без какой-либо организации.
@tadman Если вы определяете, что некоторые вещи должны идти в заголовок A, а другие - в заголовок B, то у вас также нет этой проблемы с скоплением.
Я не уверен, что вы имеете в виду. С++ довольно хорошо организован, учитывая, что много внимания было уделено разделению задач . Хотя C++ не так сильно ориентируется на шаблоны проектирования, как некоторые другие языки, он пытается придерживаться организационной философии, которая развивалась вместе с самой стандартной библиотекой.
@SamVarshavchik Технические характеристики не новы. У вас уже есть организация, когда вы определяете, что идет к какому заголовку.
«Если вы определяете, что некоторые элементы должны быть помещены в заголовок А, а другие — в заголовок Б» — вы нажимали на какие-либо ссылки в этом черновике? Он четко говорит вам, какие заголовки принадлежат какой библиотеке, и вы можете дополнительно просмотреть краткий обзор каждого заголовка, чтобы увидеть, что именно должен иметь каждый заголовок.
@Ranoiaetep Боюсь, вы можете упустить мою мысль. Мой вопрос в том, почему мы группируем эти заголовки в библиотеки. Разделение задач, организации и т. д. уже достигнуто с помощью определений заголовков.
@Brotcrunsher Нет разных библиотек в смысле, например. .so/.dll файлы. Стандарт указывает только, какие заголовки содержат какие объявления (как минимум). Он ничего не указывает на организацию определений. Обычно существует только одна библиотека в смысле одного .so/.dll. Но их также может быть много или ни одного (они могут быть внутренними для компилятора). Слово «библиотека» используется только в организационных целях внутри стандарта.
@user17732522 user17732522 Я понял. У меня вопрос, зачем нужна эта организация, если заголовки уже дают нам форму организации.
@Brotcrunsher Итак, вы хотите иметь раздел для каждого заголовочного файла в стандарте вместо текущих разделов «библиотеки»?
@ user17732522 Я не предлагаю никаких изменений в стандарте. Я просто хочу понять, почему была сделана эта (для меня в настоящее время кажущаяся произвольной) группировка. Какая нам от этого выгода? например, ссылается ли стандарт на какую-либо библиотеку, кроме определения самого себя или перечисления всех библиотек? И почему cppreference и другие сайты вообще упоминают библиотеку?
@Brotcrunsher: «Мой вопрос в том, почему эта организация требуется» «Требуется» кем?
@NicolBolas Ну, если это определяет сам стандарт, то я полагаю, что он должен служить какой-то цели. Какая это цель? Этого у нас еще нет, определив заголовки.
«кажущаяся произвольной группировка» — если вы просто смотрите на общую служебную библиотеку, она будет выглядеть произвольно, поэтому она и называется общей. Большинство других библиотек имеют гораздо более четкую тему.
@Brotcrunsher: Что вы подразумеваете под «определяет это»? Ничего не определено в том, что касается поведения C++. Вы говорите о названии глав в стандарте. У него нет никакого внутреннего значения, кроме того, что слова говорят о том, что они означают.
Это в значительной степени чисто для организации стандартного документа в удобочитаемом виде. Вы можете найти обсуждение конкретных вариантов в редакционных выпусках, таких как github.com/cplusplus/draft/issues/5124.
Цель этого та же самая, почему любые руководства делят разные части на разделы. Скажем, это руководство по эксплуатации автомобиля, каждая отдельная часть автомобиля имеет свое назначение, и вы можете просто посвятить каждый раздел определенной детали, не группируя их вместе. Тем не менее, мы сгруппировали все индикаторы приборной панели в один и тот же раздел, чтобы читателю было легче найти информацию, не зная точной информации, которую он ищет.
Большинству приложений не требуется вся библиотека, поэтому ее включение потребует много времени на компиляцию. Особенно на медленных машинах.
@NicolBolas Это хороший момент. Думаю, меня в основном смущает, почему эта информация присутствует на cppreference. Это всегда казалось мне шумом, я не вижу, кому это помогает.
У вас также есть заголовки, перечисленные в алфавитном порядке eel.is/c++draft/headers Там тоже нет конкретного значения.
Точно так же, группируя различные заголовки в единую библиотеку, это дает читателям быстрый способ узнать, что доступно. Когда люди из другого мира видят <list>, им может быть трудно представить, что были также <array> и <vector>. Сгруппировав их вместе, вы можете легко найти все доступные контейнеры.
Ответы 1
Разделение задач, организации и т. д. уже достигнуто с помощью определений заголовков.
Они?
Рассмотрим Глава 22: Утилиты. Эта глава охватывает материал, определенный в 13 отдельных заголовках. Стандарт мог бы состоять из 13 отдельных глав, но... почему? Что в этом хорошего? Есть ли какая-то причина помещать все это в отдельные главы, когда они будут намного короче, чем большинство других глав?
Рассмотрим Главу 31: Ввод/вывод. В этой главе рассматриваются вещи, определенные в 14 отдельных заголовках. Но материалы в этих заголовках часто тесно связаны друг с другом. Все потоки в конечном итоге построены на базовых классах iostream. Некоторые из них ссылаются на вещи в других заголовках, например, на возможность файловых потоков использовать объекты filesystem::path.
Но все они в конечном счете связаны с вводом/выводом. Поэтому имеет смысл объединить их все в одну главу.
У них могло бы быть 14 отдельных глав, по одной на каждый заголовок, но в этом не было бы никакой пользы. Действительно, теперь вам некуда было бы поместить раздел требований iostreams, который вообще не привязан ни к какому заголовку.
Говоря о важной информации, которая не привязана к заголовку, одним из самых важных разделов в главе «Контейнер» является раздел Требования, который применяется к каждому контейнеру. Этот раздел абсолютно необходим для понимания всего, что происходит в любой документации контейнера, и во многих случаях определяет поведение нескольких функций, определения которых не перечислены в разделе для этих отдельных заголовков. Это связано с тем, что эти функции ведут себя одинаково для всех контейнеров.
Я имею в виду, действительно ли нам нужно видеть девять отдельных повторений определений для begin, end и т. д.? Весь смысл контейнеров в том, чтобы иметь единый интерфейс, чтобы вы могли легко понять, как все работает. И если вы собираетесь иметь единый интерфейс, повторять определение этого интерфейса довольно бессмысленно.
А еще есть места, где стандарт может просто указать прямо на главу и сказать: «Все эти вещи также обладают этим свойством». Наиболее важной из них является концепция автономных реализаций. Автономные реализации — это реализации C++, которые не хотят реализовывать всю стандартную библиотеку, потому что в ней есть много вещей, которые на самом деле не нужны их клиентам (например, микроконтроллеры не заботятся о файловых системах). Но есть части стандартной библиотеки, которые должны быть реализованы даже в этих системах.
Это было более заметно в стандартах до C++23, но во многих случаях в стандарте просто говорилось: «все в этой главе/разделе должно быть самостоятельным». Это намного проще сделать, когда глава/раздел может содержать столько заголовков, сколько имеет смысл.
Вероятно, это одна из причин, по которой глава Atomic не является частью главы Threading (опять же, до C++23).
Организация предназначена исключительно для человеческих целей. Это не имеет никакого отношения к тому, как пишутся реализации, за пределами автономных вещей.
Вместо того, чтобы валить все в одну корзину, как это делает PHP? Даже C разбивает их на отдельные заголовочные файлы.