知乎上关于c和c++的一场讨论_看看高手们的想法
为什么很多开源软件都用 C,而不是 C++ 写成?
having ambiguous grammar and "gratuitous, trivial, incompatibilities with C (...) that are of no greatbenefit"Linus Torvalds也说,C++是一种可怕的语言,而使用它的一大群水平很次的程序员,使得它变得更加可怕。
"C++ is a horrible language. It‘s made more horrible by the fact that a lot of substandard programmers use it"C++本身的语法是好的,但是过于的复杂,尤其像继承这些特性被乱用了以后,面向对象的那些优势会在那些质量糟糕的代码前面完全丧失,有时候还会使得代码非常费解。
容易被误用语法特性而可能会变得很糟糕的C++,加上两位大神的抵制,理所当然在开源阵营里面流行不开。
参考: http://en.wikipedia.org/wiki/C%2B%2B#Criticism
首先,应该从开源社区的风格来说,“一个大集市”我认为是一个比较恰当的比喻,一个吵吵嚷嚷的地方,必然每个项目都可以决定自己项目的开发方式。由于现在彼此之间相互依赖的开源项目大多数都是以Linux平台为开发对象,所以自然和Linux平台自身提供的技术解决方案保持一致是一个比较容易想到的技术策略。
其次,因为Linux社区中的领军人物对C++抱有顾虑(先不谈这个顾虑是否是正确的),导致Linux社区对C++的顾虑比较大。
那么LZ的问题就可以转化成开源社区对C++的顾虑究竟是正确的,还是错误的?我的看法是既正确,也错误。而原因都在于精英治理。
由于Linux内核,以及核心的GNU软件,开发者都是技术上数一数二的精英。所以他们的产品目标,和第三方公司基于Linux平台开发的软件产品目标,略有不同。包括 Linus Torvalds在内的精英们都害怕因为不好的代码而“毁掉”一个优良的作品(当然还有其他的因素)。
而反观一些商业上比较成功的软件,并没有过分强调技术性上的“纯粹性”,而是更多的以商业利益为导向,我认为他们的成功很大程度上是因为他们深刻认识到人的思维很容易将大的问题做分解,但是比较难将小的解决方案组合成大的解决方案。而在这方面,C++应该比C更有优势,更能通过接口、通过封装降低产品各个部分的复杂度,不仅使开发者能够更容易的进行开发,也更能够让需求分析、设计更容易贴近用户实际的使用方式,而不用过分考虑其实现形式是否能够承载。
总之,这两种语言更大的区别我觉得在于设计的哲学,正是由于这种哲学上的不认同,导致了开源项目更多的使用C而不是C++。
它(C++)对C语言中存在的一些最基本的问题没有什么改进,而它对C语言最重要的扩展(类)却是建立在脆弱的C类型模型上。第十一章《你懂得C,所以C++不在话下》里还有一段话:
编程语言有一个特性,称为正交性(orthogonality)。它是指不同的特性遵循同一个基本原则的程度(也就是学会一种特性有助于学习其他的特性)。例如,在Ada中,程序员一旦明白了包(package)的工作原理,也就能够把这个知识应用于泛型包中。令人不快的是,C++中的许多特性是非正交的。精通C++的某个特性并不能给你带来什么线索或向你启发适用于其他特性的思想模型。大多数程序员选择了只使用C++中较简单的一个子集的方法。
- 披着C++外衣的C语言
- 披着C++外衣的java
===========================================
不过话说回来,我觉得是因为现在牛逼的一帮人都太老了,但是还没有脱离岗位,所以普遍有这些想法。我们组有一个超厉害的在M$干了二十几年,刚开始进来就用汇编写Fortran编译器的菊苣说,他还是不太喜欢封装得太多的东西。不过人家说得好,这只是一个喜好问题,根本不是什么好什么不好的问题。等以后CPU的核变得跟GPU一样多的时候,C语言就只能成为负担了。
原因:对于面向对象的编程语言, 除C++外还有许多更好的选项,比如Ruby、Python、PHP和Java(全都比C++排名先前);相反,C的代替品不多。
Thanks 余天升
2 C++属于实验性质的先驱,很多东西都是在C++里面广泛应用起来才推广的,面向对象,泛型等,另外继承C的一些不良东西,导致臃肿琐碎,上手容易,产生高质量的代码不容易,标准不稳定,编译器很后时才支持的比较好。
3 Linus说的很对,关键是设计,如果借鉴设计模式的一些想法,C一样可以写的很好,如果习惯了,开发效率未必会比C++低
4 现代的软件设计讲究模块化设计,各模块分工好了,整个项目不必使用同一种语言,C++的生存空间被压缩不少
5 其实C++在一些大项目上应用还是比较广的,比如symbian, windows,llvm,zeromq, mongodb, ecos,chrome, ace,qt, flash 在需要面向对象的时候,使用C来做还是有些啰嗦, 可以对比下Gtk里面的C代码。google和microsoft很喜欢c++
6 C++易学难精,很容易纠结到语言细节中,而忘了项目。
7 C++还是很有发展前途,一些必须用native code的,如果不是用C的高手,用C++还是写的快。
8 还忘了一条,C语言都是一个人从头定义的,标准委员会只是略打个补丁。C++是委员会妥协(商业政治和技术)的结果,所以混乱,标准制定进度缓慢。来自于不同的想法,没有很强的一致的风格。不过C++毕竟是需求推动起来的,所以还是符合了开发的需要。
从风格上来说,钟爱C的程序员可能不喜欢。
(2)兼容性。
虽然C++在绝大部分情况下是可以兼容C的,但在某些情况,还是不得不使用 extern C 这样的代码。
(3)我还是认为 C++ 比 C 优秀很多,如果你能很好地驾驭它。
C++ 也是在不断改进(ANSI C99、C++0x),以及很早就有了 Boost。
C++ 大师 Bjarne Stroustrup 回答过很多人的一个疑问,大致就是说“C++特性太多了,变得很臃肿,你会不会考虑裁掉一些特性”。他给的答案是“不会,无论是异常、多重继承、还是RTTI”。
原因很简单。如果说多重继承会带来问题,难道C的指针不会吗?还是那句话,只要你能很好地驾驭它!
说起来,本人一路低头,从C++学到JAVA再到OB-C……越来越被同行瞧不起……
我觉得可推广性考虑完全击败linus和大胡子
另外,开源项目很多是基础类库,而 C++ 在很多平台缺乏统一而稳定的二进制接口,无法做到二进制复用。(很遗憾,像 Boost 这样难得一见的著名开源 C++ 项目,在不尊重二进制接口的稳定性这一点上,又是臭名昭著。)那么,从节约用户的编译时间和环保的角度考虑,开源项目采用纯 C 而不是 C++ 也是有理有据的。
以上人用的语言,但太多iq70的人在用,所以大牛门纷纷不用了。
而参加开源项目的程序员,坐下来沟通的机会相对少一些,而且热衷于开源活动的人们似乎都比较爱好自由,不容易达成一致的意见。
所以干脆选择特性少一点的c语言了。
如果底层开源软件用C++写,那么当需要别的语言来使用这个软件时,即作为基础库,这时就有麻烦了。用C写了,很多语言可以真接和C的库交互。C++写的库,只能C++自己使用。必要时还必须用C到处。这也是为什么操作系统不用C++,不是不想用,而是不能用。
显然开源的老祖宗GNU(Gnu‘s Not Unix)是脱胎于Unix文化,C语言那个时候也已经得到了普遍的接受,兼容性也是最好的,用c并延续已有的c的成熟经验和代码是最自然的事。几乎所有流行的linux环境也都是在这个基础上被搭建起来的,在没有足够大的改变开发工具的必要性来推动的话,这么惯性会延续很久。(其实已经逐步在改变,比如gcc转换到c++上开发)
任何一个仔细考察和研究开源项目,或哪怕仅仅GNU项目本身的人都会发现其中蕴含的是一个巨大的宝库。实际上对于从微软/单机时代走过来的每一个人,在介入到网络(Fidonet/Internet)那一霎时,无不对突然暴露在眼前的源代码项目充满好奇,就仿佛突然发现了宝藏一般迫不及待要去挖掘。
C++乃至后续的项目的确给出了更多的方便编写代码的特性,但因为目前使用的冯氏计算机体系结构以及底层都是类Unix的操作系统也决定的的这些特性都可以通过C这个冯氏汇编语言实现,最多是偶尔稍过繁琐,这种现状暂时还不会得到改变,至少在自动生成代码的量占据一定比例以前。
那么从项目沉淀的角度看,一个最少抽象,又已经有足够底层支撑的语言是最适合用于开发希望被大众接受并广为传播的开源项目的。尽管眼下基本上各种流行语言都有不少的类似项目,但如果以一定的质量/价值/普适性阀值做一个过滤的话,基于c的项目可能存活下来的概率是最高的。越是新潮的高级的东西,要不是只是作为练手的玩具,要不往往仅局限于一个某个较窄的应用场景。
所以某些高级的东西,它们的确能够提高某个具体项目的开发效率,但其中提高最多的是那些随心所欲的成分,而真正能够拿来重用那部分沉淀/积累的东西并不会因此改变太多。人们往往发现每当一个高级的东西被发掘出来,能够得到流行的关键往往是其自身究竟积累到何种程度,实际上每次这个积累过程很可能只是一个重新制造轮子的过程,尽管这些个新造的轮子可能表面显得更加漂亮和光滑。
郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。