在C++中实现C标准库
假设操作系统/内核是用 C++ 编写的，并且不“执行”任何纯 C 风格的内容，而是公开基于成熟的 C++ 标准库构建的 C 标准库。这可能吗？如果没有，为什么？
PS：我知道 C 库是“C++ 的一部分”，但我们可以说它内部基于基于 C++ 的实现。
小更新：我似乎已经激起了一场关于我的规则“允许”的讨论。一般来说：C 标准库实现应该尽可能使用 C++/Right (tm)。我主要考虑算法以及在幕后作用于静态类对象。我并不是真正排除任何语言功能，而是试图将重点放在合理的 C++ 实现上。关于 setjmp 示例，我认为这里的有效 C（将使用 C++ C 库部分中的其他预实现或根本不使用任何其他库函数）没有理由违反我的“规则”。如果 C++ 库中没有对应的库，为什么还要争论它的使用呢。
Say an OS/kernel is written with C++ in mind and does not "do" any pure C style stuff, but instead exposes the C standard library built upon a full-fledged C++ standard library. Is this possible? If not, why?
PS: I know the C library is "part of C++", but let's say it's internally based on a C++-based implementation.
Small update: It seems I've stirred up a discussion as to what is "allowed" by my rules here. Generally speaking: the C Standard library implementation should use C++ everwhere that is possible/Right (tm). I mostly think about algorithms and acting on static class objects behind the scenes. I'm not really excluding any language features, but instead trying to put the emphasis on a sane C++ implementation. With regards to the setjmp example, I see no reason why valid C (which would use either other pre-implemented in C++ C library parts or not use any other library functions at all) here would be violation of my "rules". If there is no counterpart in the C++ library, why debate the use of it.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
是的，这是可能的。这很像从用 C++、FORTRAN、汇编程序或大多数其他语言编写的库中导出 C API。
Yes, that is possible. It would be much like one exports a C API from a library written in C++, FORTRAN, assembler or most any other language for that matter.
实际上，C++ 在很多方面都比 C 更快，因为它能够支持许多翻译时结构，例如表达式模板。因此，c++ 矩阵库往往比 c 更优化，涉及更少的临时文件、展开循环等。例如，使用变体模板等新的 c++0x 功能，printf 函数可能比 c 更快且类型安全得多。用c实现的版本。我什至能够尊重许多 C 结构的接口并评估它们的一些参数（如字符串文字）翻译时间。
不幸的是，许多人认为 c 比 c++ 更快，因为许多人使用 OOP 意味着所有关系和用法都必须通过大型继承层次结构、虚拟分派等进行。这导致一些早期的比较与这些被认为是良好用法的完全不同。天。如果您要在适当的地方使用虚拟调度（例如，像内核中的文件系统，它们通过函数指针构建 vtable，并且通常基本上在 c 中构建 c++），那么您将不会对 c 感到悲观，并且具有所有新功能，可以明显更快。
不仅速度可能得到改进，而且在某些地方，实现会受益于更好的类型安全性。 C 中有一些常见的技巧（例如，当数据必须是泛型时，将数据存储在 void 指针中）会破坏类型安全，而 C++ 可以提供强大的错误检查。这并不总是通过 C 库的接口进行转换，因为这些接口具有固定的类型，但它肯定会对库的实现者有用，并且可以在某些可能从调用中提取更多信息的地方提供帮助通过提供“as-if”接口（例如，采用 void* 的接口可以实现为通用接口，并进行概念检查以确保参数可以隐式转换为 void*）。
我认为这将是对 c++ 相对于 c 的能力的一次很好的考验。
Actually, c++ has the ability to be faster than c in many ways, due to it's ability to support many translationtime constructs like expression templates. For this reason, c++ matrix libraries tend to be much more optimised than c, involve less temporaries, unroll loops, etc. With new c++0x features like variant templates, the printf function, for instance, could be much faster and typesafe than a version implemented in c. It my even be able to honor the interfaces of many c constructs and evaluate some of their arguments (like string literals) translationtime.
Unfortunately, many people think c is faster than c++ because many people use OOP to mean that all relations and usage must occur through large inheritance hierarchies, virtual dispatch, etc. That caused some early comparisons to be completely different from what is considered good usage these days. If you were to use virtual dispatch where it is appropriate (e.g. like filesystems in the kernel, where they build vtables through function pointers and often basically build c++ in c), you would have no pessimisation from c, and with all of the new features, can be significantly faster.
Not only is speed a possible improvement, but there are places where the implementation would benefit from better type safety. There are common tricks in c (like storing data in void pointers when it must be generic) that break type safety and where c++ can provide strong error checking. This won't always translate through the interfaces to the c library, since those have fixed typing, but it will definitely be of use to the implementers of the library and could assist in some places where it may be possible to extract more information from calls by providing "as-if" interfaces (for instance, an interface that takes a void* might be implemented as a generic interface with a concept check that the argument is implicitly convertible to void*).
I think this would be a great test of the power of c++ over c.
鉴于“纯 C 的东西”与 C++ 有如此大的重叠，我不知道如何在任何东西中完全避免它，更不用说操作系统内核了。毕竟，
+操作是“纯 C 的东西”吗？ :)也就是说，您当然可以使用类等实现某些 C 库函数。使用 std::sort 实现 qsort？当然，没问题。只是不要忘记您的
extern "C"。Given that "pure C stuff" has such a large overlap with C++, I fail to see how you'd avoid it entirely in anything, much less an OS kernel. After all, is the
+operation "pure C stuff"? :)That said, you could certainly implement certain C library functions using classes and whatnot. Implement qsort using std::sort? Sure, no problem. Just don't forget your
extern "C".我看不出为什么你不能这样做，但我也看不出为什么有人会使用这样的实现。与正常的实现相比，它将使用更多的内存，并且至少会慢一些...尽管它可能不会比 glibc 差多少，反正 glibc 的 stdio 实现本质上已经是 C++ 了...（查找 GNU
libio...你会被吓到的。）I see no reason why you couldn't do it, but I also see no reason why someone would use such an implementation. It's going to use a lot more memory, and be at least somewhat slower, than a normal implementation...although it might not be much worse than glibc, whose implementation of stdio is already essentially C++ anyway... (Lookup GNU
libio... you'll be horrified.)像 Linux 这样的内核具有非常严格的 ABI，基于系统调用、ioctls、文件系统，并符合相当多的标准（POSIX 是主要标准）。由于 ABI 必须稳定，因此其表面也是有限的。这将是大量工作（特别是因为您还需要一个最低限度有用的内核），但这些标准可以用任何语言实现。
编辑：您也提到了 libc。它不是内核的一部分，并且由于前面提到的 ABI，libc 的语言可以与内核的语言完全无关。与内核不同，libc 需要是 C 语言，或者对 C 具有非常好的 ffi 性。带有
extern C部分的 C++ 就符合要求。Kernels like Linux have very strict ABI, based on syscalls, ioctls, filesystems, and conforming to quite a few standards (POSIX being the major one). Since the ABI has to be stable its surface is also limited. It would be a lot of work (particularly since you need a minimally useful kernel as well), but these standards could be implemented in any language.
Edit: You mentioned the libc as well. That is not part of the kernel, and the language of the libc can be entirely unrelated to that of the kernel, thanks to the aforementioned ABI. Unlike the kernel, the libc needs to be C or have a very good ffi for C. C++ with parts in
extern Cwould fit the bill.是的，这是可以做到的。
LLVM C 库是用 C++ 实现的。
但尚未完成（2024 年 3 月）。
关于实施的有趣会议演讲：The Challenges of Implementing the C Standard Library in C++ - Siva Chandra Reddy - CppNow 2023
有趣的先有鸡还是先有蛋的问题：C++ 标准库使用 C 库头文件，并且大多数实现都使用 C 运行时。
Yes, it can be done.
The LLVM C Library is implemented in C++.
Not complete though (March 2024).
Interesting conference talk on the implementation: The Challenges of Implementing the C Standard Library in C++ - Siva Chandra Reddy - CppNow 2023
Interesting chicken-and-egg problem: the C++ standard library uses C library header files and most implementations make use of the C runtime.