用C ++实现C标准库

Question

假设OS /内核是用C ++编写的，并没有“做”任何纯C风格的东西，而是公开了基于完整的C ++标准库构建的C标准库。这可能吗？如果没有，为什么？

PS：我知道C库是“C ++的一部分”，但我们可以说它是基于基于C ++的实现。

小更新：我似乎已经激起了关于我的规则“允许”的讨论。一般来说：C标准库实现应该尽可能使用C ++ / Right (tm)。我主要考虑算法并在幕后操作静态类对象。我不是真的不包括任何语言功能，而是试图强调理智的C ++实现。关于setjmp示例，我认为没有理由为什么有效的C（它将使用其他预先在C ++ C库部件中实现或根本不使用任何其他库函数）这将违反我的“规则”。如果C ++库中没有对应物，为什么要讨论它的用法。

Answer 1

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

Answer 2

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

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

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

我认为这将是对c ++相对于c的强大考验。

Answer 3

鉴于“纯C东西”与C ++有如此大的重叠，我无法看到你如何完全避免它在任何东西，更不用说操作系统内核了。毕竟，+操作是“纯C的东西”吗？ ：）

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

Answer 4

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

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

Answer 5

我认为没有理由不能这样做，但我也没有理由有人会使用这样的实现。它会比正常的实现使用更多的内存，并且至少有点慢......虽然它可能不比glibc差很多，glibc的stdio的实现无论如何已经基本上是C ++ ......（Lookup GNU {{ 1}} ......你会感到恐惧。）