Why is the C++ standard library bundled with the compiler instead of the os?

Question

I am sorry if this is a naive question, but there's something I can't get my head around.

Why is the C++ standard library bundled with different compiler implementations (g++'s libstdc++ and clang's libc++) instead of coming bundled with a (UNIX-like) Operating System, just as, say the C standard library does? Why isn't it maintained alongside the C library, considering that it's a superset of it?

Answer 1

The source code of the C++ library is bundled with the GCC sources. This makes sense, because the C++ library goes hand in hand with the C++ language. It is not an operating system component. Certain aspects of it, like memory management and I/O, do interface with OS facilities, but much of it doesn't.

On the other hand, the actual bundling of the C++ library is the job of the operating system distro (for instance some flavor of GNU/Linux).

Ultimately, it is your distribution which decides how libstdc++ is packaged. For instance, it might make sense for it to be a standalone package (which might even need to appear in several versions). This is because libstdc++ provides a shared library, and that shared library is needed as a dependency by other packages, whether or not a compiler is installed. And some packages might only work with a specific version of this library.

"Part of the OS" or "part of the compiler" don't really make sense: the question is "part of what package", and that is distro-specific, because when you build the GCC suite, your build scripts can then pick apart the temporary install tree into arbitrary packages based on your vision of how to organize a distro.

Suppose we made a "ceeplusplusy" OS distro. Then the C++ library could be considered and essential component of the OS. That is, suppose the core applications that are needed just to bring up the OS are all rewritten in C++ and all use the library: things like a system daemon, shell, "getty" and so on. Then the C++ library is needed in early boot stages. Ultimately, what is OS and what isn't?

Answer 2

On a Mac, you will find both libc.dylib (Standard C library) and libc++.dylib (Standard C++ library) in the /usr/lib directory. On an iOS device, you won't find them (easily), but they are both there as well. Quite clearly, they are not part of the compiler, because they are essential for practically all programs to run, and they are present even if you never installed any compilers.

Answer 3

The basic reason is that there is no standard C++ ABI -- every compiler tends to have its own ABI that is different from and incompatible with that of other compilers. On the other hand, most OSes define a standard C ABI that they use and supply a standard C library for, and all C compilers for that OS support that ABI.

Answer 4

The C library is also maintained separately: both glibc and Windows's msvcr* (don't know the details on Mac). The fact that is "comes with the OS" is that all (most of) the binaries are linked against it, so nothing would work without it. Granted, same could be said of the C++ standard library, but not quite so strict.

The compiler often provides extensions which library writers use to facilitate development. When a new feature is implemented, the library is adapted. Sometimes these changes are breaking. In the case of glibc/libstdc++(/libc++?), backwards compatibility is maintained inside the library (using versioned symbols). In the case of Windows' CRT, various incompatible versions appeared of both the C and C++ standard libraries, coupled to each compiler version. Also: in the case of Visual Studio, the compiler tends to break ABI between versions, so "the OS" would have to come with all versions of the libraries.

PS: granted, for Windows, it might have been "cleaner" to include newer CRT/C++lib versions in Windows Update. Other choices were made way back when, and most stuck until now.

Answer 5

Operating systems in general do not support languages. They only support for their own system calls. In most operating systems this support is provided as part of the C library because C has the lowest level linkage. Other languages and runtimes (such as C++, python, etc) build their runtime support on top of the OS's system call support library.