Linux开发者 H. Peter Anvin 在邮件列表中重启了关于 Linux内核C代码转换为C++的讨论，并陈述了自己的观点。说之前先看一下这个话题的历史背景。
早在2018年4月1日，Andrew Pinski提议将 Linux 内核源码转为 C++，在文中写道之所以引入是由于以下优点：
(1) 内联模板函数，使得诸如 cmpxchg() 和 get_user() 这样的功能的实现更加清晰。
(2) 内联重载函数，使得诸如 static_branch_likely() 这样功能的实现更加清晰。
(3) 类继承。例如，所有那些需要包含基本 inode 结构并且必须通过类似以下方式访问的 inode 封装器：
inode->vfs_inode.i_mtime当你可以改为：
inode->i_mtime本次重新开启这个话题，Anvin提到：
自 1999 年以来，C 和 C++ 都有了很大的发展，事实上，在我个人看来，C++ 最终"成长"为一种更好的C，适合操作系统那样的嵌入式编程内核的缩影。我是说，作为内核中大量宏和内联汇编黑客的作者。
真正让我这么说的是，我们最近要求的 gcc 特定扩展的很多东西实际上是在标准 C++ 中相对容易实现，并且在许多情况下，允许在无需全局代码更改的情况下改进基础设施。
在我的选择中，C++14 是具有合理元编程支持的“最低”版本。没有早期版本的类型地狱（C++11 拥有大部分，但 C++14 填补了一些关键的缺失部分）。
然而，在我看来，C++20 确实是主要的游戏规则改变者；尽管早期版本可以玩很多 SFINAE hacks，但它们也给出了绝对无用的信息作为错误消息。C++20 添加了概念，这使得实际上获得合理的错误成为可能。
从上面可以看出几个关键点：
C++成熟性
标准C++的易用性
C++14和C++20的增强支持
元编程的便利性
当然除了以上的内容之外，还有陈述了不选用Rust的原因，相比Rust，C++的语法更加熟悉，而且通过一些清理，现有的C代码可以逐步转换为C++。作者认为Rust的语法不仅不必要，而且内核开发人员需要花费大量时间来适应。
SUSE Lans的Jiri Slaby表示支持Linux内核采用C++的倡议。最初发布内核补丁的Red Hat的David Howells也回应，支持这次讨论。
我们将看到LKML（Linux内核邮件列表）上的这次讨论是否能够取得足够的进展，以支持现代C++代码——或者至少是Linux内核中的某个定义的C++14~20子集——在2024年及以后。过去，Linus Torvalds曾对C++表示强烈反感，但我们将看到是否潮水终于已经转变，他是否对最近的C++标准更为满意，或者他是否仍然坚决主张将Linux内核保持在C语言中。
直到2022年，Linux内核才开始从C89过渡到C11。特别是如果有共识允许在内核中使用C++14/C++20的子集，可能在将更广泛的编译器支持推出之前，还需要一些时间，然后才能提高基础编译器的要求。即使得到Torvalds的神奇认可，也不是一个轻率的决定。
相关引用：
https://lore.kernel.org/lkml/152261521484.30503.16131389653845029164.stgit@warthog.procyon.org.uk/ https://lore.kernel.org/lkml/1681813.1704843645@warthog.procyon.org.uk/ https://lore.kernel.org/lkml/3465e0c6-f5b2-4c42-95eb-29361481f805@zytor.com/ https://www.zhihu.com/question/639186621
往期干货：
未来已来：C++17 并行STL性能测评
热度更新，手把手实现工业级线程池
