假设操作系统/内核是用 C++ 编写的，并且不会“做”任何纯 C 风格的东西，而是公开基于成熟 C++ 标准库构建的 C 标准库。这可能吗？如果不是，为什么？
PS：我知道 C 库是“C++ 的一部分”，但假设它在内部基于基于 C++ 的实现。
小更新：似乎我在这里引发了关于我的规则“允许”什么的讨论。一般来说：C 标准库实现应该尽可能使用 C++/ Right (tm)。我主要考虑算法和在幕后对静态类对象进行操作。我并没有真正排除任何语言特性，而是试图将重点放在理智的 C++ 实现上。关于 setjmp 示例，我看不出为什么有效的 C（将使用其他在 C++ C 库中预先实现的部分或根本不使用任何其他库函数）会违反我的“规则”。如果 C++ 库中没有对应的库，为什么还要争论它的使用。
实际上，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 的强大测试。
是的，这是可能的。这很像从用 C++、FORTRAN、汇编程序或大多数其他语言编写的库中导出 C API。
鉴于“纯 C 的东西”与 C++ 有如此大的重叠，我看不出你如何在任何事情中完全避免它，更不用说操作系统内核了。毕竟，+操作是“纯 C 的东西”吗？:)
也就是说，您当然可以使用类和诸如此类的东西来实现某些 C 库函数。使用 std::sort 实现 qsort？好没问题。只是不要忘记您的extern "C".
像 Linux 这样的内核具有非常严格的 ABI，基于系统调用、ioctl、文件系统，并且符合很多标准（POSIX 是主要标准）。由于 ABI 必须是稳定的，它的表面也是有限的。这将是很多工作（特别是因为您还需要一个最低限度的有用内核），但这些标准可以用任何语言实现。
编辑：您也提到了 libc。这不是内核的一部分，由于前面提到的 ABI，libc 的语言可以与内核的语言完全无关。与内核不同，libc 需要是 C 或对 C 具有非常好的 ffi。带有部件的 C++extern C符合要求。
我看不出你为什么不能这样做，但我也看不出有人会使用这样的实现的理由。它将使用更多的内存，并且至少比正常的实现要慢一些......尽管它可能不会比 glibc 差多少，反正它的 stdio 的实现本质上已经是 C++......（查找 GNU libio.. . 你会吓坏的。）