偶看新闻连词英文缩写:C与C 语言之争：网友观点争论精彩语录之二 , 语言,程序员,linus,网友,模块,抽象,设计,观点,接口,程序, ,
来源：百度文库 编辑：偶看新闻 时间：2024/04/27 09:48:29
【CSDN 报道】昨天由CSDN发布的Linux之父发表了对C++的不满之后，很多的软技术专家们就这一问题提出了自己的观点，随后诸多位网友也积极参与了讨论，现在展示给大家的就是他们的精彩语录。
支持观点：
1，网友roy_hu
C++野心太大，希望包罗万有，以致语义实在是太复杂了。而这个复杂性在我看来是不必要的，因为它只
增加了
一的抽象方式，functional programming就很不错。
2，网友Atry
基本来说C++太复杂了，很多特性用不到，可能是我比较初级吧，不过感觉C++的抽象能力要想用同样的C
实现出来，并不是短时间就能达到并超越的。
因为新手可以用面向对象语言写出过程化程序，而老手可以用过程化语言写出面向对象的程序。
我被当头一棒之后最大的感悟就是，应该把 C++ 看成是比 C 更低级的语言。这样，使用 boost 和模板
的时候就不会因为它们带来的坏味道而有负罪感了。
把 C++ 看成是比 C 更低级的语言，还有一个暗示，就是在接口上，用 C 函数加结构，而不用带复杂继
承结构的类。因为，继承也被我看成是一种在模块内部实现中便于
设计层面的东西。
“...唯一真正重要的部分是设计...”Linus大师一语道破天机！
到了一定程度似乎就是在学设计了，成功的设计事半功倍，失败的设计天天翻工......
3，网友wangor
1.我很牛 2.我写C++很牛 3.可是我写C比写C++更牛 4.我和linus一样牛
4，网友 missdeer
其实用C实现一个程序，也是有一些模式的，这些模式决定了如何使用C的某些突出的特性。写C程序如果
能用好宏与函数回调，就足以满足很多程序了。用C的好处就是，我能掌握每一块内存在哪里。
5，网友 cnm
用C++的人大部分都有一个心智上的问题，以至会抵触，鄙视一些自己不喜欢的东西。儿子太顽皮，东搞
搞西搞搞，爸爸教训一下不务正业的儿子，儿子就不认爸爸了，甚至要把爸爸消灭，爸爸也很生气，发
誓要给儿子更严厉的教训....
中立观点：
1，网友Linker M Lin
同样的设计思路来做一件工作, C/C++ 在模块api 级别的区别:
C 的话, 模块之间用 free function, function point, handle, struct 来定义接口
C++ 用 interface (abstract class), class 来定义接口
C++ 的方式是耦合度更高的方式, 哪些function 属于哪个 class, class 之间的关系, 出现在了 API
这层, 导致了云风说的修改框架带来的麻烦问题.
C 的 API 方式耦合度更低些.
从另外一个角度讲, C++ 的方式更白盒, 会让 API 的使用者更能够理解模块内部的一些逻辑关系, 从而
更有可能使用正确 --- 代价就是, 逻辑关系一旦变化, 就比较麻烦.
2，网友zcpro
博主说的没错，关键是设计。我也是个喜欢简洁的人，但我还是在用c++，因为c++的资源太多了。我现
在倾向于这样使用c++，使用c++的抽象能力做设计，定义模块接口，这里只用虚函数，不用其它复杂的
高级特性，类似com的做法；然后在实现模块时程序员爱怎么写就怎么写，只用c也可以，呵呵。
3，网友Cofyc
语言的进化一定是为了能写出逻辑复杂度更高，用现在的眼光来看更为庞大的应用。为了达到这个目标
，抽象能力是最关键的一点，因为这能帮助程序员理解复杂的系统。所以，如果是做较为大型的应用的
话，不管用什么语言，抽象能力都是很关键的。不要看windows的api都是c接口，那是为了兼容（其实也
并非都是c接口，很多高级应用早就使用com了，现在又有了.net）。不用害怕重写或者重新设计接口，
重构是不可避免的，只要每次重构能离目标更近。如果兼容是很重要的，那么就保留旧模块，然后设计
新接口新模块，象directx做的那样，不是挺好的。
反对观点：
1，网友 Atry
楼主的帖子可以总结为一句话“使用C++设计代码不如C”
进而颠覆了C++的设计目标“抽象、封装和代码重用”
那么这些目标不正确么？回答当然是否定的，否则就不会有java和C#大行其道。
那么有10软件开发经验，使用C++编写了数以10W计的代码的楼主，为什么会转而选择C而弃用C++呢?对于linus教主的言语会产生如此强烈的共鸣？
回答这个问题，可以从二人从事的工作上得到答案。楼主是国内著名游戏引擎的开发者，而linus则是专
注于os内核的开发者和维护者。他们进行软件开发的设计决策都是以“性能”优先的。
孟老大说，linus曾经试图使用C++写内核，后来失败了；而楼主也把使用C++完成的游戏引擎重新用C来
写。我想可能是面对同样问题的时候，设计决策影响了他们对语言的选择，毕竟C所擅长的，C++不如。
但是世界上有如此之多的成功的C++软件项目，是否使用C重写能够带来更好的效果呢？
C++仍然是C的进化，虽然它包含了太多的东西使它难以掌握，但是它仍然变得越来越好。特别是C++0x中
可能做出对于线程模型和GC的修订，有助于使用者更好的完成设计。
2，网友david
论了那么多还是请大家不要忘记C不过是C++的一个子集.用不用C++的那些特性是使用者自己在经过考虑
过后得出的.自己选择的东西最后反过来批判只能说明当初悟道不深亦或者现在还未悟道.语言所做的只
是提供一些认为可以在某些情况某些环境下能够帮助使用者更好编码的特性.记住,用不用在于你自己,谁
也没有强迫你非要那样或这样.不过是提供多一种选择罢了.所以所有讨论的焦点不是语言的好坏而是你
为什么做出这样的选择.
3，网友lxlxdw
好吧，我来唱唱反调。
学习期。 c，简单，干练。简单到没什么好学的。有用的技能都是在实际运用中获得exp然后lvup的。可
以这么说，初学者可以很快得掌握c，但是基本上却什么都不能做。立竿不能见影。这是c的简单干练所
决定的，是必然的。 c++，复杂，强大。c++的这些特点已经无须论证。遍地开花的垃圾c++程序员用铁
一般的事实说明了一切。针对于与c的比较，仍然来说说立竿见影的问题。我的观点是，虽然这一点c++
做得比c好一些，但是仍然不能达到立竿见影的程度。结论，就这个阶段来说，不分胜负。
开发期。在任何软工项目都处于“硬件受限”的时代和环境下，c是毫无疑问的王者。（当然，如果你脑
容量可堪负荷，请使用asm）但是在现在，情况分2种。第1种，我是一个独裁者。当我需要清楚地知道我
的代码做了什么的时候，c->asm仍然是最适合的合作者。这种人多半是战斗在“硬件受限”的原始时代
。Linus就处于这样一种时代，所以他不得不用c。不要告诉我linux可以跑在多么牛B的机器上，内存可
以多么的大，这是p话，linux的kernel必须不能用尽一切可以触及的资源，因为它只是一个承载其他东
西的方舟，他必须委屈自己假装是在一个超级受限的环境下工作，把美味的梨子让出来给依赖着它的兄
弟姐妹们。所以，kernel类的开发者毫无疑问是战斗在一个“硬件受限”的原始时代，c->asm是他们最
好的合作者。 ps.游戏引擎也算半个“硬件受限”环境。虽然不需要承载如kernel般繁多的东西，但是
引擎最终将被用来产生实作品，从设计者的角度出发，也必须在一定规模——没错，就是规模——上考
虑到由这个引擎所生产出来的东西将要产生的负荷——这毫无疑问地成为了一个“受限”的环境。——
但是尽管如此，c->asm也不一定就是最优解，在我的观点来看，这是语言无关的——当然，目前可以做
出的选择不多，就个人而言，我仍然选择了c++。第2种，我是一个追求高产的商人。在性能要求不太严
苛的情况下，c就是一个渣。太多的东西需要自己去做，这意味着将会带来冗长的开发周期，这会导致成
本的急剧增长，包括各种可量化的（人力物力财力）和不可量化的（团队稳固性团队士气）成本。因此
，在这种环境下，c就是一个渣。c++毫无疑问比c做得好。但是，在这个领域里，c和目前的c++都已经失
去了辉煌的宝座，新生代的
负。但是c在这一阶段具有稳定、明确的应用领域，算是小胜吧。
运行期。仍然是分成2种情况，效率关键和效率不关键的。在避开其他环节的情况下，前者当然比后者更
受欢迎。但是，运行期的效率直接与开发期的质量相关，因此运行期的事又是不可能和开发期完全隔开
的。 “不管用什么样的语言，都可以写出糟糕的程序。”——这话也可以反过来说，“用任何一种语言
，都可以写出优秀的程序。” 因此，在我眼中，这仍然是一个语言无关的问题。不要把失败的理由放在
你无法控制的地方，优秀的进化者会改变自己适应环境。——这是我的观点，因此，我更希望自己能成
为“用任何一种语言，都可以写出优秀的程序”这样一个开发者。我认为，每一个以成为优秀开发者为
目标的程序员，都应该以这样一种精神为指导，虽然不一定要确实地做到，但是应该具备这样一种精神
。用更容易理解的话来说，就是要做到手中有剑心中无剑（请注意这跟武侠小说上的说法是反的-_-!）
结论，既然都语言无关了，当然没有胜负之说。
维护期。 OK，这实际上是一个软工项目中生命周期最长的阶段。这里涉及了很多东西，最主要的就是3
个方面：调试、维护、复用。这三个议题每一项都可以大书特书再书还要书。既然是生命期中最长的一
个阶段，因此c对c++的重量级攻击放在这里当然就会很有效果。在维护上的代价而言，结构过程化的c比
抽象对象化的c++便宜太多了。这是“结构过程化”与“抽象对象化”的根本不同所造成的差别。用程序
员们更能够理解的方式来说，c就像一个链表，要增减head很方便；而c++就像一个动态数组，要insert
[0]或者remove[0]就要牵一发而动全身！但是，c真的就很好维护么？非也！一个疯狂使用#define的c程
序，不会比一个滥用oo特性的c++程序更好调试和维护。因此，这仍然是与开发期工作的质量息息相关的
。结论，好吧，我不得不说，在我眼中c和c++仍然不分胜负。
综上所述，c和c++在我眼中不分好坏，具有同等的地位。他们分别代表了两种不同的编程思想。 “结构
过程化”的c带来的好处是赋予程序员更为强大的控制力，和维护期可以“断章取义”的灵活性——但是
代价是更多你不得不亲历亲为的工作。 “抽象对象化”的c++带来的好处是更为贴近现实的思维要求，
以及更具亲和力的“人机交互接口”——当然，代价是需要你练好足够的基本功来了解c++在背后到底做
了些什么，以及在维护期和复用阶段你可能要面临的“抽筋”式的痛苦。
作为一个拥有美好愿望的程序员，我希望有一种语言，既能给我c的强大控制力和维护期的灵活性，又能
给我c++的亲和力和强大的——好吧，我承认我比较喜欢template那种拐弯抹角的东西——脑力训练（—
_,—），然后，又能轻易地满足KISS的原则——这将可以让我非常简单地找到高质量的合作者——毕竟
怪物级的c/c++程序员不是像现在的本科生一样遍地都是。而且基于c/c++的灵活性——这里叫做不确定
性更好——这一特征，每个怪物级的c/c++程序员都有很大可能不能跟另一个怪物互相咬合他们脑袋里高
速转动的齿轮——如果你非要那么做，这很可能会带给你更多的机会让你的项目走火入魔，甚至停摆，
最后以自爆收场。
但是遗憾的是，目前这只能是一个美好的愿望而已，我不得不采取折中的办法来找一些代替品。因此，
目前我的做法是，用c的规则来写c++的程序，略微地用一些可以被我完全控制的c++的特性（模板的编译
期编程技术很赞，可以为运行期的效率和正确性带来很大的好处），最根本的出发点是建立在获得强大
控制力和可预期的维护期工作量的目的之上的，当然，还有不能忽视的效率问题——我的目标是一个可
扩展的游戏引擎。
胡言乱语了一堆也不知道说了些啥……最后做个总结性发言吧：c和c++都不是什么好东西，但是正如
windows也不是什么好东西一样，我们却非得要用它们——至少在可以预见的一段不会算短的时期内。
另外，撇开c/c++的比较说点跑题的话。
c++目前确实处于一个相当尴尬的境地，高不成低不就，过于复杂庞大的身躯又成为了他能够被更熟练掌
握的门槛。c++目前有两条路可走，一是朝c退过去，二是朝更高之处攀登。但是无论走哪一边，都是“
强敌环视”，要想闯出一片新的天空，恐怕需要剑走偏锋了。至于是不是一定要偏着走，偏又要怎么个
偏法，我也说不出个所以然来，且让我们拭目以待吧。而c，很可能将会止步于“硬件受限”的时代吧，
然后在这个时代和环境下再一点一点地进化，最终与c++将来的终点完全分道扬镳。
个人以为，程序语言的发展以后将会明确地分出两个方向，一个是以c为代表的“底层亲和”的语言，它
们的特点是将给于程序员最大的控制能力，让一切尽在程序员的掌握之中。另一个将是以不断发展的新
兴高级语言为代表的方向，也可能是c++以后的方向，它们的特点是不断地将底层的东西从程序员的眼前
隐藏起来，让程序员的门槛降得更低，充分地体现出KISS原则，并从而提高生产力和生产效率。