Warum wird die C++-Standardbibliothek mit dem Compiler und nicht mit dem Betriebssystem gebündelt?

Es tut mir leid, wenn dies eine naive Frage ist, aber es gibt etwas, um das ich mich nicht kümmern kann.

Warum ist die C++-Standardbibliothek mit verschiedenen Compiler-Implementierungen gebündelt (g++‘s libstdc++ und clang‘s libc++) anstatt mit einem (UNIX-ähnlichen) Betriebssystem gebündelt zu kommen, so wie es beispielsweise die C-Standardbibliothek tut? Warum wird es nicht neben der C-Bibliothek gepflegt, wenn man bedenkt, dass es sich um eine Obermenge davon handelt?

Der Hauptgrund ist, dass es keine Standard-C++-ABI gibt – jeder Compiler neigt dazu, seine eigene ABI zu haben, die sich von der anderer Compiler unterscheidet und mit dieser nicht kompatibel ist. Andererseits definieren die meisten Betriebssysteme eine Standard-C-ABI, die sie verwenden und für die sie eine Standard-C-Bibliothek bereitstellen, und alle C-Compiler für dieses Betriebssystem unterstützen diese ABI.

Betriebssysteme unterstützen im Allgemeinen keine Sprachen. Sie unterstützen nur ihre eigenen Systemaufrufe. In den meisten Betriebssystemen wird diese Unterstützung als Teil der C-Bibliothek bereitgestellt, da C die Verknüpfung auf der niedrigsten Ebene hat. Andere Sprachen und Laufzeiten (wie C++, Python usw.) bauen ihre Laufzeitunterstützung auf der Unterstützungsbibliothek für Systemaufrufe des Betriebssystems auf.

Die C-Bibliothek wird auch separat verwaltet: sowohl glibc als auch msvcr* von Windows (ich kenne die Details für Mac nicht). Die Tatsache, dass es “mit dem Betriebssystem geliefert wird”, ist, dass alle (die meisten) Binärdateien dagegen gelinkt sind, sodass nichts ohne es funktionieren würde. Zugegeben, das Gleiche könnte man von der C++-Standardbibliothek sagen, aber nicht ganz so streng.

Der Compiler stellt häufig Erweiterungen bereit, die Bibliotheksautoren verwenden, um die Entwicklung zu erleichtern. Wenn ein neues Feature implementiert wird, wird die Bibliothek angepasst. Manchmal brechen diese Änderungen. Im Fall von glibc/libstdc++(/libc++?) wird die Abwärtskompatibilität innerhalb der Bibliothek aufrechterhalten (unter Verwendung von versionierten Symbolen). Im Fall von CRT von Windows erschienen verschiedene inkompatible Versionen sowohl der C- als auch der C++-Standardbibliothek, die mit jeder Compiler-Version gekoppelt waren. Außerdem: Im Fall von Visual Studio neigt der Compiler dazu, ABI zwischen Versionen zu unterbrechen, sodass “das Betriebssystem” mit allen Versionen der Bibliotheken geliefert werden müsste.

PS: Zugegeben, für Windows wäre es vielleicht “sauberer” gewesen, neuere CRT/C++lib-Versionen in Windows Update aufzunehmen. Andere Entscheidungen wurden vor langer Zeit getroffen, und die meisten blieben bis heute hängen.

Der Quellcode der C++-Bibliothek ist mit den GCC-Quellen gebündelt. Das ist sinnvoll, weil die C++-Bibliothek Hand in Hand mit der C++-Sprache geht. Es ist keine Komponente des Betriebssystems. Bestimmte Aspekte davon, wie Speicherverwaltung und E/A, haben eine Schnittstelle mit Betriebssystemeinrichtungen, aber vieles davon nicht.

Die eigentliche Bündelung der C++-Bibliothek ist dagegen Aufgabe des Betriebssystems Distribution (zum Beispiel eine Variante von GNU/Linux).

Letztendlich entscheidet Ihre Distribution, wie libstdc++ gepackt wird. Beispielsweise kann es sinnvoll sein, dass es sich um ein eigenständiges Paket handelt (das möglicherweise sogar in mehreren Versionen erscheinen muss). Dies liegt daran, dass libstdc++ eine gemeinsam genutzte Bibliothek bereitstellt und diese gemeinsam genutzte Bibliothek als Abhängigkeit von anderen Paketen benötigt wird, unabhängig davon, ob ein Compiler installiert ist oder nicht. Und einige Pakete funktionieren möglicherweise nur mit einer bestimmten Version dieser Bibliothek.

“Teil des Betriebssystems” oder “Teil des Compilers” macht nicht wirklich Sinn: Die Frage ist “Teil von welchem ​​​​Paket”, und das ist distrospezifisch, denn wenn Sie die GCC-Suite erstellen, können Ihre Build-Skripte dies tun Teilen Sie den temporären Installationsbaum in beliebige Pakete auf, basierend auf Ihrer Vorstellung davon, wie Sie eine Distribution organisieren.

Angenommen, wir haben eine „ceeplusplusy“-OS-Distribution erstellt. Dann könnte die C++-Bibliothek als wesentlicher Bestandteil des Betriebssystems betrachtet werden. Angenommen, die Kernanwendungen, die nur zum Hochfahren des Betriebssystems benötigt werden, sind alle in C++ neu geschrieben und verwenden alle die Bibliothek: Dinge wie ein Systemdämon, eine Shell, “getty” und so weiter. Dann wird die C++-Bibliothek in frühen Bootphasen benötigt. Letztendlich, was ist OS und was nicht?

Auf einem Mac finden Sie sowohl libc.dylib (Standard-C-Bibliothek) als auch libc++.dylib (Standard-C++-Bibliothek) im Verzeichnis /usr/lib. Auf einem iOS-Gerät werden Sie sie nicht (leicht) finden, aber sie sind beide auch da. Ganz klar, das sind sie nicht Bestandteil des Compilers, da sie für praktisch alle Programme zum Ausführen unerlässlich sind und auch dann vorhanden sind, wenn Sie nie einen Compiler installiert haben.