Linus大神再度炮轰C++,力挺C语言

blogdaren 2012-08-17 抢沙发 1001人次
Torvalds最 近在一封邮件中说明了内核开发需要使用C语言而非C++的理由。
Name: Linus Torvalds (torvalds@linux-foundation.org) 6/8/10
anon2 (anon@anons.com) on 6/8/10 写道:
>效率对于内核的开发是个至关重要的问题。
>大部分志愿者为内核贡献代码,所以在相
>同条件下,使用更高效的语言能让你的工
>作效率提升,从而更快更出色的完成开发。

事实上,你错了

志愿者贡献的代码很优秀,而且他们似乎没有觉得语言的效率是个障碍。如果改换语言真的能提高效率,那么这将是使大众受益的事情——不仅仅是经济方面 的。一行行的写代码,而不和用户交流,即使使用再有效率的语言都是无用的,很多大型项目都有这个问题的。

Linus大神再度炮轰C++,力挺C语言


内核方面,我们有大约1000个志愿者者为每一个内核的释出做着贡献 (3个月前统计的结果)。现在有更多的人加入,但是我更为担心的不是代码,而是 编码方面的持续性和linux内核的发展方向。现在,我已不写代码很多年。我目前主管志愿者的代码是否进入内核,如果代码可以进入内核,我就说ok,进去 吧;如果不能,我就说No——当然这种情况比较少。

如果想做好一个产品,最重要的就是要与客户进行交流。内核的编写也是如此,缺乏交流 是整个项目的瓶颈……避免交流缺失最好的办法就是拥有共同的 “culture”(信仰吧……),或者拥有共同的默契感(原文:潜规则,汗之~)。我们有很多文档指导人们如何去做以及怎样去做,但是在不同文化背景的 人们面前,这些文档是那么苍白无力……

(有很多书在介绍文化,你甚至可以在大学取得一个相关的PhD学位,然后穷极一生去学习,但是,但是你却从来没有深入了解过自己……)

c 语言呢,也有自己的“文化”(Unix也是如此——让我想起了KISS)。一个语言,就应该简单而明确,而不是复杂冗余。c++有一个绝对让我不 爽的“特性”—— context-dependent,这只是意味着, 当你阅读代码时,本地视图(local view)却不能给你任何帮助。

这,在交流上可是个大问题……在庞大的项目中,人们对不是自己开发的模块并不了解,能快速理解其他模块中函数的确切含义才能提高开发效率,而C++ 引入的各种抽象则使代码变得晦涩难读。

如果你想提交代码(或者补丁),是不是感觉 “sctp_connect()” 比 “connect()” 简洁而且明了呢?(匈牙利命名?) ,剩下的交给编译器吧,编译器能知道你写的是sctp协议模块的,并完成一切。

项 目开发中,我们尽量使用补丁和分支,邮件列表等形式,而不是对源码进行整体修改,这是因为唯一重要的在于改变,而不是结果。所以,这也是我们避免 歧义和代码关联性(context)的根本原因。——尤其是在内核项目上,绝对不能有半点马虎。绝大多数软件工程上都是如此,其实在日常交往中也应该如 此:说话含糊不正常的得不到好处。

因此,一个语言应该简单而明确。你不必顾虑过多,也不用学习冗长的语法和你不需要的东西。如果每个人都 是项目专家,那么隐含方式调用函数 (implicit context)是个不错的主意——这就是为什么真正深奥的科学文献,基本上都是晦涩难懂的,除非你是一个专家,拥有大量的背景知识以及要素,才能有所了 解。但是如果是一个多人参与的大型项目,呃,这几乎是不可能的。

例如,我非常了解 VM 部分的代码,但我仍然需要读取各文件系统和网络的代码。即使像我这样了解的人,仍然把代码写的简明扼要,绝不会有任何“隐藏代码”。c就是这样一个语言, 读代码,就能知道它的作用。一个函数用来做一件事,而这个函数也只作这一件事情,不会再出现一些“微妙的问题”——这是“哪个版本的一个函数调用”。

这也就是为什么我认为c语言“简约而不简单”——尤其是对于一个os的内核来说,尤为重要;在特定的编程或系统亦是如此。这也是为什么我不认为在所 有项目中c都适合的原因。

不过,c++……我真得不认为它有什么出色的地方。垃圾回收和并发等等,这些才是真正重要的特性。可是c++……完全落在了c后边……

linus

原文: http://www.realworldtech.com/forums/index.cfm?action=detail&id=110618&threadid=110549&roomid=2

版权声明:除非注明,本文由( blogdaren )原创,转载请保留文章出处。

本文链接:Linus大神再度炮轰C++,力挺C语言

发表评论:

您的昵称:
电子邮件:
个人主页: