Прошу прощения, если это наивный вопрос, но я кое-что не могу опустить.
Почему стандартная библиотека С++ в комплекте с различными реализациями компилятора (g++ libstdc++ и clang libc++) вместо того, чтобы поставляться в комплекте с (UNIX-подобной) операционной системой, так же, как, например, стандарт C библиотека делает? Почему он не поддерживается рядом с библиотекой C, учитывая, что это надмножество?
Основная причина в том, что нет стандартного С++ ABI - каждый компилятор имеет свой собственный ABI, который отличается от других компиляторов и несовместим с ними. С другой стороны, большинство ОС определяют стандартный C ABI, который они используют и предоставляют стандартную библиотеку C, и все компиляторы C для этой ОС поддерживают это ABI.
Операционные системы в целом не поддерживают языки. Они поддерживают только свои системные вызовы. В большинстве операционных систем эта поддержка предоставляется как часть библиотеки C, потому что C имеет связь самого низкого уровня. Другие языки и среды выполнения (например, С++, python и т.д.) Создают поддержку в режиме исполнения в верхней части библиотеки поддержки системных вызовов ОС.
Библиотека C также поддерживается отдельно: как glibc, так и Windows msvcr * (не знаю деталей на Mac). Тот факт, что "приходит с ОС", состоит в том, что все (большинство) двоичных файлов связаны с ним, поэтому без него ничего не будет работать. Конечно, то же самое можно сказать о стандартной библиотеке С++, но не настолько строгой.
Компилятор часто предоставляет расширения, которые используют библиотеки для облегчения разработки. Когда новая функция реализована, библиотека адаптируется. Иногда эти изменения ломаются. В случае glibc/libstdС++ (/libС++?) В библиотеке поддерживается обратная совместимость (с использованием версий с символами). В случае с Windows CRT были показаны различные несовместимые версии как стандартных библиотек C и С++, связанных с каждой версией компилятора. Кроме того: в случае Visual Studio компилятор имеет тенденцию прерывать ABI между версиями, поэтому "ОС" придется использовать со всеми версиями библиотек.
PS: предоставлено для Windows, возможно, было "более чистым" включение новых версий CRT/С++ lib в Центр обновления Windows. Другие варианты были сделаны еще раз, когда и наиболее застряли до сих пор.
Исходный код библиотеки С++ связан с источниками GCC. Это имеет смысл, потому что библиотека С++ идет рука об руку с языком С++. Это не компонент операционной системы. Некоторые его аспекты, такие как управление памятью и ввод-вывод, взаимодействуют с объектами ОС, но в большинстве случаев этого не происходит.
С другой стороны, фактическое объединение библиотеки С++ - это работа операционной системы distro (например, некоторый вкус GNU/Linux).
В конечном итоге именно ваша дистрибуция решает, как упаковывается libstdС++. Например, для него может иметь смысл быть автономным пакетом (который может даже появиться в нескольких версиях). Это связано с тем, что libstdС++ предоставляет общую библиотеку, и эта разделяемая библиотека необходима как зависимость от других пакетов, независимо от того, установлен ли компилятор. Некоторые пакеты могут работать только с определенной версией этой библиотеки.
"Часть ОС" или "часть компилятора" на самом деле не имеет смысла: вопрос является "частью какого пакета", и это зависит от дистрибутива, потому что, когда вы создаете пакет GCC, ваша сборка скрипты могут затем разделить временное дерево установки на произвольные пакеты, основываясь на вашем видении того, как организовать дистрибутив.
Предположим, что мы создали дистрибутив ОС ceeplusplusy. Тогда можно было бы рассмотреть библиотеку С++ и существенный компонент ОС. То есть предположим, что основные приложения, которые необходимы только для создания ОС, все переписаны на С++, и все они используют библиотеку: такие вещи, как системный демон, оболочка, "getty" и т.д. Тогда библиотека С++ необходима на ранних этапах загрузки. В конечном счете, что такое ОС, а что нет?
На Mac вы найдете как libc.dylib(стандартную библиотеку C), так и libС++. dylib (стандартная библиотека С++) в каталоге /usr/lib. На устройстве iOS вы не найдете их (легко), но они оба есть. Совершенно очевидно, что они не являются частью компилятора, потому что они необходимы для практически всех запущенных программ, и они присутствуют, даже если вы никогда не устанавливали компиляторы.