在 C++ 中实现 C 标准库答案

【问题标题】：Implement the C standard library in C++在 C++ 中实现 C 标准库
【发布时间】：2011-02-24 19:53:18
【问题描述】：

假设一个操作系统/内核是用 C++ 编写的，并且没有“做”任何纯 C 风格的东西，而是公开了基于成熟 C++ 标准库构建的 C 标准库。这可能吗？如果不是，为什么？

PS：我知道 C 库是“C++ 的一部分”，但假设它在内部基于基于 C++ 的实现。

小更新：似乎我在这里引发了关于我的规则“允许”什么的讨论。一般来说：C 标准库实现应该尽可能使用 C++/Right (tm)。我主要考虑算法和在幕后对静态类对象进行操作。我并没有真的排除任何语言特性，而是试图将重点放在理智的 C++ 实现上。关于 setjmp 示例，我看不出为什么有效的 C（将使用其他在 C++ C 库中预先实现的部分或根本不使用任何其他库函数）会违反我的“规则”。如果 C++ 库中没有对应的库，为什么还要争论它的使用。

【问题讨论】：

我看不到内核的实现语言和用户代码之间的关系。
@JackN：完全没有，请重新阅读这两个问题。你/我的“重复”专门关于 pthreadstd::thread，这是关于标准 C 库与 C++ 的。
@AProgrammer：肯定有几个库函数需要与内核交互才能工作（我在想文件 I/O 等...）？
内核和用户代码之间的接口通常在汇编中完成，因为它需要处理器特定的东西，而不是用于语言 ABI（例如软件中断或类似 x86 上的 SYSCALL 指令）。
您显然可以提供一个将其包装为官方 OS 接口的 DLL，但该接口与内核本身的实现语言无关。我会使用类似于 C 的东西来促进与所有语言的接口（因此不使用非常 C 特定的可变参数函数之类的东西）。

标签： c++ c standard-library

【解决方案1】：

是的，这是可能的。这很像从用 C++、FORTRAN、汇编程序或大多数其他语言编写的库中导出 C API。

【讨论】：

【解决方案2】：

实际上，c++ 在很多方面都比 c快，因为它能够支持许多翻译时构造，例如表达式模板。出于这个原因，c++ 矩阵库往往比 c 更优化，涉及更少的临时性、展开循环等。使用新的 c++0x 功能（如变体模板），例如 printf 函数可能比 c++ 更快且类型安全在 c 中实现的版本。我什至能够尊重许多 c 构造的接口并评估它们的一些参数（如字符串文字）的翻译时间。

不幸的是，很多人认为 c 比 c++ 更快，因为很多人使用 OOP 意味着所有的关系和使用都必须通过大型继承层次结构、虚拟分派等发生。这导致一些早期的比较与考虑的完全不同这些天很好用。如果您要在适当的地方使用虚拟调度（例如，像内核中的文件系统，它们通过函数指针构建 vtables 并且通常基本上在 c 中构建 c++），那么您将不会对 c 感到悲观，并且具有所有新功能, 可以明显更快。

不仅速度是一种可能的改进，而且在某些地方实现会受益于更好的类型安全。 c 中有一些常见的技巧（比如当数据必须是泛型时将数据存储在 void 指针中）会破坏类型安全，并且 c++ 可以提供强大的错误检查。这并不总是通过接口转换到 c 库，因为它们具有固定的类型，但它肯定会对库的实现者有用，并且可以在某些可能从调用中提取更多信息的地方提供帮助通过提供“as-if”接口（例如，采用 void* 的接口可以实现为通用接口，并通过概念检查参数是否可隐式转换为 void*）。

我认为这将是对 c++ 对 c 的强大测试。

【讨论】：

【解决方案3】：

鉴于“纯 C 的东西”与 C++ 有如此大的重叠，我看不出你会如何在任何事情中完全避免它，更不用说操作系统内核了。毕竟，+ 操作是“纯 C 的东西”吗？ :)

也就是说，您当然可以使用类和诸如此类的东西来实现某些 C 库函数。使用 std::sort 实现 qsort？好没问题。只是不要忘记您的extern "C"。

【讨论】：

我特别说“C 库”确实区分了语言库。有区别，这很重要。

【解决方案4】：

我看不出你为什么不能这样做，但我也看不出有人会使用这样的实现的理由。它将使用更多的内存，并且至少比正常的实现要慢一些......尽管它可能不会比 glibc 差多少，反正它的 stdio 的实现本质上已经是 C++......（查找 GNU @987654321 @...你会被吓坏的。）

【讨论】：

所以会差很多，但仔细想想，与最流行的开源 C 库相比，差不了多少或相同？
@rubenvb，说得好，但我想我同意 R. 无论如何。如果 glibc 是用 C++ 实现的，它会甚至更大。这只是对 glibc 功能完整程度的一次尝试。 glibc 是瑞士陆军电锯战术核武器小刀。 :-)
人们忍受 glibc 的大小、缓慢和拒绝遵循标准，因为它是 那里有什么。与许多人在 Windows 上忍受 MSIE 的原因几乎相同。我不认为你可以编写一个像 MSIE 一样糟糕的新浏览器并让人们采用它，我不认为你可以编写一个像 glibc 一样糟糕的新标准库并让人们采用它。
实际上，我认为认为 c++ 是对 c 的悲观化的信念对于那些不了解 c++ 能做什么的人来说是一个神话。
你可以随心所欲地想，但这不会改变现实。使用 C++ 习惯用法几乎不可能获得故障安全代码（无故障情况），因为几乎所有内容都需要动态分配。

【解决方案5】：

像 Linux 这样的内核具有非常严格的 ABI，基于系统调用、ioctl、文件系统，并且符合很多标准（POSIX 是主要标准）。由于 ABI 必须是稳定的，它的表面也是有限的。这将是很多工作（特别是因为您还需要一个最低限度的有用内核），但这些标准可以用任何语言实现。

编辑：您也提到了 libc。这不是内核的一部分，由于前面提到的 ABI，libc 的语言可以与内核的语言完全无关。与内核不同，libc 需要是 C 或对 C 具有非常好的 ffi。C++ 中的部分 extern C 符合要求。

【讨论】：