为什么C ++标准库与编译器捆绑在一起而不是os？

Question

如果这是一个天真的问题，我很抱歉，但有些事我无法理解。

为什么C ++标准库与不同的编译器实现（g++的{​​{1}}和libstdc++的{​​{1}}）捆绑在一起而不是捆绑在一起（UNIX-比如操作系统，就像C标准库那样吗？为什么它不与C库一起维护，考虑到它是它的超集？

Answer 1

基本原因是没有标准的C ++ ABI - 每个编译器都倾向于拥有自己的ABI，它与其他编译器的ABI不同并且不兼容。另一方面，大多数操作系统定义了他们使用的标准C ABI并为其提供标准C库，并且该操作系统的所有C编译器都支持该ABI。

Answer 2

操作系统通常不支持语言。他们只支持自己的系统调用。在大多数操作系统中，此支持作为C库的一部分提供，因为C具有最低级别的链接。其他语言和运行时（例如C ++，python等）在OS的系统调用支持库之上构建运行时支持。

Answer 3

C库也是单独维护的：glibc和Windows的msvcr *（不知道Mac上的细节）。事实是＆＃34;附带操作系统＆＃34;是因为所有（大部分）二进制文件都与它相关联，所以没有它就没有任何工作。当然，可以说C ++标准库也是如此，但不是那么严格。

编译器经常提供库编写者用来促进开发的扩展。实现新功能时，将调整库。有时这些变化正在破裂。对于glibc / libstdc ++（/ libc ++？），库内部保持向后兼容性（使用版本化符号）。对于Windows＆＃39; CRT，各种不兼容的版本出现在C和C ++标准库中，并与每个编译器版本相结合。另外：在Visual Studio的情况下，编译器往往会破坏版本之间的ABI，因此＆＃34; OS＆＃34;必须附带所有版本的库。

PS：授予，对于Windows，它可能已经更清洁＆＃34;在Windows Update中包含较新的CRT / C ++ lib版本。其他选择在以后的时候就已经过了，而且大多数情况一直持续到现在。

Answer 4

C ++库的源代码与GCC源捆绑在一起。这是有道理的，因为C ++库与C ++语言齐头并进。它不是操作系统组件。它的某些方面，如内存管理和I / O，与操作系统设施进行交互，但其中大部分都没有。

另一方面，C ++库的实际捆绑是操作系统发行版的工作（例如某些GNU / Linux版本）。

最终，您的发行版决定了如何打包libstdc ++。例如，它可能是一个独立的包（甚至可能需要出现在几个版本中）。这是因为libstdc ++提供了一个共享库，并且无论是否安装了编译器，都需要该共享库作为其他包的依赖项。有些软件包可能只适用于该库的特定版本。

“操作系统的一部分”或“编译器的一部分”实际上没有意义：问题是“什么包的一部分”，这是特定于发行版的，因为当你构建GCC套件时，你的构建然后，脚本可以根据您对如何组织发行版的愿景，将临时安装树拆分为任意包。

  

假设我们制作了一个“ceeplusplusy”OS发行版。然后可以考虑C ++库和操作系统的基本组件。也就是说，假设只需要启动操作系统所需的核心应用程序都是用C ++重写的，并且都使用库：系统守护程序，shell，“getty”等等。然后在早期启动阶段需要C ++库。最终，什么是操作系统，什么不是？

Answer 5

在Mac上，您将在/ usr / lib目录中找到libc.dylib（标准C库）和libc ++。dylib（标准C ++库）。在iOS设备上，您不会（轻松）找到它们，但它们也都存在。很明显，它们不是编译器的一部分，因为它们对于几乎所有运行的程序都是必不可少的，即使您从未安装过任何编译器，它们也会存在。