皇上,还记得我吗?我就是1999年那个Linux伊甸园啊-----24小时滚动更新开源资讯,全年无休!

六年前关于是否将Linux内核从C语言转换为现代C++语言的讨论再次被提及

六年前关于是否将Linux内核从C语言转换为现代C++语言的讨论再次被提及

关于将 Linux 内核转换为支持现代 C++ 代码的前景,一个已有六年历史的 Linux 内核邮件列表讨论再次被点燃。现有的Linux 内核主要由 C 代码和各种手工编写的汇编语言构成,加上 Linux 内核支持 Rust 的工作也在不断增加。虽然目前还不清楚是否有足够的力量将其变为现实,但 Linux 内核社区邮件列表已重启讨论,探讨未来将 Linux 内核 C 代码转换为 C++ 的可能性。

早在 2018 年 4 月 1 日,红帽工程师大卫-豪威尔斯(David Howells)就提出了一组 45 个补丁,开始将内核转换为 C++。这将允许主线内核使用内联模板函数、内联重载函数、类继承以及其他目前 Linux 内核的 C 代码不支持的功能。那天很难进行认真的讨论,最终这些补丁在 Linux 内核邮件列表上停留了六年,没有引起太多讨论。

但昨天,长期从事 Linux 开发的彼得-安文(H. Peter Anvin)回应了内核邮件列表的主题。Anvin 写了一篇长长的 LKML 帖子,围绕为什么 Linux 内核的 C++ 最终可能是正确的时机提出了他的理由:

“安德鲁-平斯基(Andrew Pinski)最近知道了这个主题。我知道它是在 2018 年 4 月 1 日发布的,要么是个玩笑,要么可能被当成了玩笑。不过,我认为它有其合理性,我将在此尝试激发我的观点。”

自 1999 年以来,C 和 C++ 都有了长足的发展,而事实上,在我个人看来,C++ 终于”长大”了,对于操作系统内核所体现的嵌入式编程而言,它是一种更好的 C 语言。我是作为内核中大量宏和内联汇编Hacks的作者才这么说的。

让我这么说的真正原因是,我们最近提出的许多针对 gcc 扩展的要求,其实在标准 C++ 中很容易实现,而且在许多情况下,无需修改全局代码即可改进基础架构。

在我看来,C++14 是拥有合理元编程支持的”最低”版本,它拥有大部分元编程支持,却没有早期版本的类型地狱(C++11 拥有大部分元编程支持,但 C++14 填补了一些关键缺失)。

在我看来,C++20 才是真正改变游戏规则的主要因素;虽然早期版本可以使用大量 SFINAE hacks,但它们也提供了完全无用的错误信息。C++20 增加了一些概念,这使得真正获得合理的错误信息成为可能”。

对于那些可能会提出”用 Rust 重写 C 代码!”的人,Anvin 在他的信息中主动补充道:

“现在,为什么不使用 Rust 呢?首先,Rust 使用的是不同的语法(在我看来,往往是无端的),不仅所有内核开发人员都需要非常熟悉,才能获得与 C 相同的”感觉”,而且将 C 代码转换为 Rust 并不是一件可以零敲碎打的事情,而现有的 C 代码经过一些清理就可以编译为 C++。”

SUSE Lans 的 Jiri Slaby 表示支持 Linux 内核的 C++ 计划。最初发布内核补丁的红帽公司的 David Howells 也表示支持这一讨论。

我们将拭目以待 LKML 讨论的结果,以及在 2024+ 年是否最终有足够的动力支持现代 C++ 代码–或者至少是一些定义的 C++14~20 子集–在 Linux 内核中的应用。Linus Torvalds 过去一直热衷于反对 C++,但如果他对最近的 C++ 标准更加满意,或者他仍然坚持使用 C 语言来维护 Linux 内核,那么我们就能看到潮流是否最终转向了。

直到 2022 年,Linux 内核才开始从 C89 转向 C11。特别是如果达成共识,允许在内核中使用 C++14/C++20 编程子集,那么在提高基本编译器要求之前,可能还需要一段时间才能通过,以便推出更广泛的编译器支持。

转自 六年前关于是否将Linux内核从C语言转换为现代C++语言的讨论再次被提及 (msn.cn)