用C++实现C标准库

Question

假设一个操作系统/内核是以C++为主要编程语言，不使用纯C的编程方式，而是基于完整的C++标准库构建的C标准库。这种情况可能吗？如果不行，为什么？

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

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

- rubenvb

---

我无法看出内核实现语言和用户代码之间的关系。 - AProgrammer

@AProgrammer：肯定有几个库函数需要与内核交互才能工作（我在想文件 I/O 等等）吧？ - rubenvb

@Steve：在这个上下文中，C的意思是使用仅用C语言实现的C库函数调用或C风格，而C++可能更为合适。我知道我在这里说得含糊不清，但我希望你能理解我的意思。 - rubenvb

另外一个问题是，C++除了通过C头文件之外没有提供任何访问信号的方法，因此这是另一种情况，即“用C++实现C库”，你的C++程序员只能放弃他们的优秀原则，按照C的方式进行操作，否则就必须放弃提供库作为库的想法，而是编写整个C环境、编译器等。 - Steve Jessop

@评判：你不能只是将它们实现为库。例如，setjmp/longjmp必须在调用者的堆栈上操作，因此要链接到它，你必须做更多的事情，不仅要遵守操作系统的调用约定，还必须使用它理解的堆栈布局。这就是我所说的不仅仅是一个库的意思。显然，你可以用几乎任何语言来实现整个C语言。就这个问题而言，我认为它是关于以一种rubenvb描述的提供库的方式逐步实现它。 - Steve Jessop

Answer 1

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

- Judge Maygarden

Answer 2

实际上，由于C++支持许多翻译时间构造（如表达式模板），因此在许多方面，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的强大力量的绝佳测试。

- ex0du5

Answer 3

考虑到“纯C代码”与C++有很大的重叠部分，我不明白你如何在任何情况下都完全避免它，更不用说操作系统内核了。毕竟，+操作是“纯C代码”吗？ :)

话虽如此，你当然可以使用类等方式来实现某些C库函数。使用std::sort实现qsort？没问题。只要别忘了你的extern "C"。

- bdonlan

---

我特别提到“C库”是为了区别于语言<->库。这里有差别，并且很重要。 - rubenvb

Answer 4

像Linux这样的内核有非常严格的ABI，它基于系统调用、ioctl、文件系统并符合一些标准（其中POSIX是主要标准）。由于ABI必须保持稳定，因此它的表面也很有限。虽然这些标准可以用任何语言实现，但这需要大量工作（特别是你还需要一个足够有用的最小内核）。

编辑：您还提到了libc。那不是内核的一部分，而且libc的语言可以完全不相关于内核，这要归功于前面提到的ABI。与内核不同，libc需要是C或具有非常好的C ffi。带有extern C组成部分的C++可以胜任。

- Tobu

Answer 5

我不认为你不能这样做，但也不明白为什么会有人使用这种实现方式。它会消耗更多的内存，而且运行速度至少会稍微慢一些，相比于 glibc 来说可能并不会更糟糕，因为它的 stdio 实现实际上已经是 C++ 的了。不过如果你查看 GNU 的 libio，你可能会感到震惊。

- R.. GitHub STOP HELPING ICE

---

那么相比最流行的开源 C 库，情况会更糟糕得多，但仔细考虑并不会更糟或者与其相同吗？ - rubenvb

人们容忍glibc的体积、速度慢和拒绝遵循标准，因为它就是现成的。这也是为什么很多人容忍Windows上的MSIE的原因。我认为你不可能写一个像MSIE那样糟糕的新浏览器并让人们采用它，我也不认为你可以写一个像glibc那样糟糕的新标准库并让人们采用它。 - R.. GitHub STOP HELPING ICE

关于“动态分配”，C++并不比C本质上更慢，所以我不确定你的观点是什么。事实上，通过类型安全的slabs，C++可能会更快。我在我的答案中提到了printf作为速度受益的例子。你能否列举出一个单一的API，它必然比C更慢？ - ex0du5

C语言可以解决许多问题，而无需进行动态分配。通常在C++中实现这一点的唯一方法是放弃C++习惯用法，并使用丑陋的语言编写代码，即C和C++的交集。 - R.. GitHub STOP HELPING ICE

你没有回答我的问题，只是以不同的方式重申了你的答案。你有没有任何具体的例子，证明C++习惯用语必须被抛弃或者C允许的单一解决方案不需要动态分配，而C++却需要？一个例子会更好地阐明你的观点，因为到目前为止我感到很困惑。生命周期管理是C++的优势之一，因为它有构造函数/析构函数，并且类型可以使用静态多态性（泛型编程）嵌入，而不需要动态分配，在C中则需要使用void指针。 - ex0du5