云风的 BLOG: 看着 C++ 远去

感谢你的留言, 我终于知道为什么我尤其厌恶OOP, 这种厌恶感一直说不出来.
所以, 我不喜欢java. 我更加喜欢 c With Class(不怕你笑话).
而我一直无法表达这种感觉. 谢谢你点醒了我.

OOP 的关键是类型系统!!! 这句话真的是醍醐灌顶. 其它的继承, 多态只是附加功能,
而类型系统才是本质, 也是真正区别与面向过程. 面向过程写法, 就是一个无状态
, 通用的函数黑盒. 如 qsort. 由于它是通用的. 所以不容易将其模块化. 如果代码中
全都是这种通用的通用函数, 那维护是个灾难.

所以, OOP 允许你针对特定需求构建一个类型系统. 为这个类型系统实现一个
qsort(struct foo*). 这样很容易将其模块化.

至于, 继承, 多态虽然有好处, 但是缺少了它, 仍然可以设计精妙的 oop 系统.

至于为什么讨厌 java. 是因为主次颠倒. 过于注重继承, 所以 java 代码中总是
非常冗余, 几个类就解决的问题, 非要设计一个继承框架出来.

而我为什么讨厌 cpp, 是因为cpp做的事情太多了. 它追求完美, 所以
我只是想设计一个类, 我要给他重载 xx, 以便能对接 xx.
于是, CPP 里面的设计越来越通用, 越来越复杂, 有一种写通用库的感觉.

Posted by: Anonymous | (83) February 9, 2022 01:30 AM

无论走的多远
最后还是会返璞归真

Posted by: friendan | (82) September 22, 2018 12:38 PM

同样云风讲的side effect观点，语言特性越多则越容易被误用，把C++作为C的有益补充是最好的，多数C++项目难以维护不是因为没有设计而是因为过度设计，越简单的才越有效，最新的C++ 0X又加入一堆标准，但在降低代码量的基础上却增加了调试的难度

Posted by: magicyang87 | (81) August 15, 2012 11:42 AM

我觉得，如下陈述，也算是所有支持OO的语言的通病吧：
所谓面向对象，从本质上说，是允许你去扩充这种语言本身的类型系统；所不同者，也就是究竟允许你的扩充可以在多大程度上去模拟原生类型。

各种支持OO的语言里，C++无疑是做的最为彻底的一种（我觉得不用加“之一”了^_^）；而其他如c#、java等等，则都做了更多限制——这些限制包括“禁止运算符重载”以降低类型模拟的层次和难度、“取消指针运算”以降低原生类型本身的复杂度（从而在另一个角度降低用户类模拟原生对象的难度），如此等等。

但，无论如何，只要在一定程度上“允许模拟原生类型”，那么同时也就提出了另一个要求，即：你必须模拟好该语言的原生类型，至少也要描述清楚你的类和原生类型间的不同之处。

对于java、c#之类“阉割版”（没有贬义）面向对象语言来说，这个模拟并不很难——虽然不可避免地有点额外的小麻烦。

但对C++这个雄心勃勃的语言来说，情况就完全不一样了——你包装了个复数类？好吧，重载四则运算吧——它必须能够与其他已知未知的数值类型互动。
像java一样重载一大堆的equals？然后再在扩充了其他如有理数类时增加新的重载函数？
恶心。

于是，你不得不动用泛型（虽然java禁止了运算符重载，但基于现实需要，它很快也要支持泛型了）。

于是乎，犹如老鼠拖木锨般，虽然初始目标是想做一个很小巧的东西，最后却发现自己不得不为了将其融于语言本身（或者说让人能以一致的风格使用），而不得不写出越来越多的东西。
这方面，java、C#要好不少，毕竟没有那么复杂的原生类型或/和不允许全面模拟原生类型。
但从本质上来说，情况并没有改变；反而是付出了性能和表达能力上的代价。
并且，java终于也要支持泛型了。

越是追求技术，越是追求尽善尽美，OO语言用起来就越是痛苦——这个东西能否拷贝？暂时似乎还用不到，禁了吧，以后再写（不禁，就是bug！）。

诸如此类本不必管的无聊问题，程序员却丝毫不能怠慢——为避免他人误中“边际效应”陷阱，在设计新类时，我们就不得不写出更多的代码。

从本质上说，OO语言是一个frame work，它封装了面向对象这个设计模式——c写的unix有个泛文件概念，一切最终可归结到输入输出上的东西都是文件：谁能说它不是面向对象的设计思路呢？

所以说，c、汇编，都可以是面向对象的；设计者可以根据实际需要裁剪，给出最为精巧简洁的方案。

而OO语言，则强迫设计者使用语言给出的框架，做出完全面向对象的设计——java干脆不允许非对象的东东出现：这就在方案的可裁剪性上出现了问题。
尤其是对于C++来说：写一个类，就要考虑是否允许它如原生类型般工作；写一个算法，就要考虑它能否一劳永逸地处理所有类似问题；倘想解决所有这些问题，最终就会归结到模板；要动用模板，就要考虑编译器支持能力，要学习最新的泛型技巧……

总而言之：一旦你想设计一个自给自足的、完美的类，不知不觉间，程序的设计重心就从“解决实际问题”转移到“写一个通用库”上了。

比如，在使用C时，仅仅为解决实际需要，为一个结构体写一个可完成工作的处理函数，是很自然很完美的；而到了C++中，这二者的结合有多丑陋，就不用多说了吧。

换句话说，就是使用OO语言，非常容易陷入“过度设计”这个泥潭；尤其是对那些工程经验不是很足、并且喜欢钻研底层的人来说。

即使工程经验很足，上面那种很实用的“半拉子类”，看起来也是极其恶心的。不如老老实实写成c结构体+一个处理函数的模式。

OO和泛型，本质上是用来写库的（而且是设计良好的库）；不问青红皂白就拿来做工程，怎么可能不恶心？

虽然，用对了地方，它们真的很强大。

滥用OO、泛型和设计模式，则是另一种恶心。

我遇到过这样一个糟糕的设计：一个模式套一个模式，反正一眼看上去不知道他要干什么。等分解清楚了才发现：他一开始启动了10多个线程同时读取文件内容；然后等所有这些线程都完成了，启动10多个线程同时开始分析；再等所有线程都分析完了，再同时开10个线程写入数据库；等都写完了，重新开10个线程去读文件……

该并行时不并行，不该并行乱并行（并行读磁盘，不越并行越慢才怪——特殊设计的大型存储系统除外）；不过设计模式用的倒真溜，一口气上了5、6种。

设计模式是好东西，但不是随便怎么用还都是好东西。OO、泛型亦然。

Posted by: ghost | (80) May 9, 2008 03:08 PM

现在有点云风的同感了，虽然用得不咋地。

Posted by: pass86 | (79) April 24, 2008 02:38 AM

是不是，你已经进入到结构当中去了；也可能是因为一个人写代码时间太久了；

Posted by: 半边 | (78) May 15, 2007 02:25 PM

从我们现在的项目来看（几十万行代码，几百个源文件），C 语言写的模块更容易和人协作。

这是C++的死穴，虽然我是无比欣赏boost的狂热者，但是更多的人没时间去搞明白boost

Posted by: Atry | (77) April 4, 2007 07:48 PM

从现实的一些近期代码来看，就是不考虑源码复用，找到最快最简洁的方式针对性的解决问题。尽量隐藏住细节，不为尚不存在的需求做工作。

--------------------------

但是需求并不是复用的唯一目的。相比“最快最简洁的方式针对性的解决问题”，我追求的是“最短的代码解决问题”。

《代码大全》提到，bug数量和代码长度成正比，忘了在哪里看到，云风前辈你也承认C++比C代码要短吧。被前辈称为滥用模板的boost，和相同功能的其它代码相比，boost代码之短更是到了夸张的程度。

“最快最简洁”是主观标准。但“代码最短”是客观标准。

Posted by: Atry | (76) April 4, 2007 07:32 PM

呵呵多谢指教，期待早日能看到我的编程感悟2 呵呵。希望看到系统的描述一种思想，一个体系，一种方法。
我用C++ 没有用复杂的功能，就是用class. 没有stl 没有模板。就是用它来表述面向对象的思路。用对象来领域建模，用模式来进行设计求精。觉得这种方式可表达，可学习。

Posted by: yaoyang | (75) April 4, 2007 06:43 PM

现阶段我用的方法没有规范，说好听点叫无招胜有招。目前还没有能力总结，文字的表述比较困难。

从现实的一些近期代码来看，就是不考虑源码复用，找到最快最简洁的方式针对性的解决问题。尽量隐藏住细节，不为尚不存在的需求做工作。

引用《Unix 编程艺术》中文版 P101 最后一段话：“OO 设计理念的价值最初在图形系统、图形用户界面和某些仿真程序中被认可。使大家惊讶并逐渐失望的是，很难发现 OO 设计在这些领域以外还有多少显著优点。”

当时我读到这句话时，颇有共鸣。

Posted by: Cloud | (74) April 4, 2007 06:08 PM

因为现在流行的是面向对象方法论，所以我也是对这个方向熟悉一点。除了这个以外模板范式是我暂时还不会的。面向过程的思路，觉得比较简单。云风你使用的是什么方式呢？很是好奇呵呵。就拿上面我举的2个例子来说。你的方法论是什么呢？很想学习一下。因为我手里只有一把锤子，所以任何东西都是钉子。哈哈

Posted by: yaoyang | (73) April 4, 2007 05:45 PM

我想我能理解云风的感觉

Posted by: nothanks | (72) April 4, 2007 04:41 PM

多态可以用到很多场合，大多数问题用面向对象来理解和实现也都是合理的。

但是，这不等同于只有这一种方法。

最近一年写了不少程序，如果是以前，我会面向对象，会 C++ 解决问题。但是当我尝试不用这些时，发现另一些编程的感觉。

绕来绕去，也只有 GUI 的框架不用多态会有些难受，别的倒没这种感觉。

Posted by: Cloud | (71) April 4, 2007 03:23 PM

再比如分层结构里面

|UI层|

|应用层|

|领域层|

|基础支撑层|

支撑层要做到和逻辑隔离，也就是说要做到面对多态的逻辑处理，不用观察者模式，又如何达到呢？用函数指针来说不是太生硬了？

Posted by: yaoyang | (70) April 4, 2007 02:58 PM

多态的应用只在 GUI 方面吗？我举一个例子。比如一个职称评定系统
|职称|

|德| |智| |体|

|毛思| |邓理| 。。。。

用一个清晰的类图结构来表述不是很清晰吗？

|---->|职称|
|

|复合职称| |简单职称|

Posted by: yaoyang | (69) April 4, 2007 02:53 PM

多态不是为了解决问题，多态是为了更好的理解问题。

楼下说的好

Posted by: nothanks | (68) April 4, 2007 11:45 AM

多态不是为了解决问题，多态是为了更好的理解问题。

不论是否同意面向对象的人，都会同意“模块”和“接口”，分歧只在于“接口”的尺度。是100行代码一个接口还是10000行代码一个接口。

100行一个接口的好处在于每一个接口内部逻辑足够简单，以至于很难出现bug，即使出现bug也容易修复。缺点在于接口间的关系设计上容易出现bug。

可维护性可理解性上看，100行一个接口的实现和整个大的模块的外部接口的距离比较远，因此初次接触代码会比较难搞清楚代码是怎么运行的。100行一个接口的逻辑的复杂度都体现在接口的关系中，他的好处就在于如果弄清楚接口间的关系，会非常容易维护和理解代码。

对于100行一个接口的做法，画一些图来解释依赖关系，理解起来并不像第一眼看到那么困难。

Posted by: Atry | (67) April 4, 2007 09:05 AM

目前，我感觉真正需要用到多态的只是 GUI 的框架。

大部分应用，非要使用面向对象来解决问题的其实不多。

大多数情况下，面向对象为了解决复杂的问题而存在，其结果却导致了问题的复杂化。

Posted by: Cloud | (66) April 3, 2007 07:52 PM

如果不用C++ 难道用函数指针实现多态，如果不用多态？面向对象的方法论又如何实现？

Posted by: Anonymous | (65) April 3, 2007 07:18 PM

为什么不说C++ 对面向对象的支持呢。这个才是精髓吧

Posted by: Anonymous | (64) April 3, 2007 07:16 PM

C or C++, just a tool.没有绝对的优点和缺点。我在外企工作，项目原因要熟悉6种程序语言，JAVA、C,C++,Perl,Python,javascript，要熟悉四国语言，英语、德语、日语、西班牙语，经常游走在欧洲和东南亚。感觉国外的程序员对程序语言从来没有绝对的厌、或绝对的爱，是通过应用领域来决定使用哪种程序语言而已。So take it easy :)

Posted by: bluedeep | (63) April 3, 2007 04:40 PM

C或C++

Posted by: bluedeep | (62) April 3, 2007 04:33 PM

你们说的C++比C牛B的地方,Java和C#都比C++要更牛B.

Posted by: Anonymous | (61) March 30, 2007 12:50 PM

C++是一个很好的工具，但要会善用，写代码的时候，思想很重要，不善于组织代码，滥用C＋＋的功能，当然会头晕，即使用C也好不到哪去。这样的代码我是不会去读的。

Posted by: iceeye | (60) March 20, 2007 11:06 AM

现在的顶级游戏引擎如unreal3都是C++的呀.

Posted by: Anonymous | (59) March 15, 2007 11:42 AM

东西摆在那里给你用，用不用是你自己的事情，没人强迫，你自己用完了觉得恶心，那是你自己的问题，不要归结到语言上。每种语言都有它自己的使用范围，就像用j2ee写桌面应用一样，你可以那么做，但是可能很恶心人，但是它的长处还是在网络。

以前觉得你很了不起，甚至有些崇拜。但是近几年看着你在不断的改变，说话的方式，看待事物的态度渐渐令我感到恶心了。

Posted by: Anonymous | (58) March 7, 2007 05:21 PM

小声地说一句，其实我是Java万能论的拥护者。Java必将取代C++，哇哈哈哈。至于什么Lua、Python，不过是Java的一个子集。

Posted by: Atry | (57) March 6, 2007 01:48 PM

看着 C++ 远去是对的，但是回到C已经是不可能的了。现在是21世纪了。

Posted by: Atry | (56) March 6, 2007 01:44 PM

到现在为止，流行的基于虚拟机的GC都保证是“安全”的。

刚才这几个回复所说的不就是想要一个不安全的GC么？不安全的GC会有什么结果，我没见过，不敢下结论。

不过我知道，目前，高级语言的语言本身已经足以取代C++绝大多数应用了。包括C++的所谓底层应用，比如Managed DirectX。Java语言本身也足以进行任何底层应用。

长远的看，手动汇编优化是比不过编译器优化的，而编译时优化也比不过运行时代码优化。

JIT、HotSpot这些技术的成熟，已经没有任何理由阻止我们使用高级语言了。

Posted by: Atry | (55) March 6, 2007 01:41 PM

c,里玩点3个星的指针,或者大量的没有typedef的函数指针的程序也会让你恶心的.
写出的程序易用性和可读性是最高的目标,如果程序写得都让人觉得恶心,只能说明作者写的程序的目的了(炫耀自己的技术?).任何语言都有写的烂的,这不能归结为语言的缺陷.就是写C程序我也要用C++编译去编译.为吗?老兄还是想想再说C++吧.

Posted by: makefile | (54) March 5, 2007 01:11 PM

这么快看到云风回贴了。
最近我也是正在看GC，打算把GC技术引入到游戏资源管理里来。
上面也说过我更愿意GC以第三方库或可选资源管理方式来加入C++，能同时提供便捷的资源管理和底层的控制。
但对于像JAVA、C#这种方式来支持GC的语言，我认为程序员很难能得到源码级的资源控制权。虽然它们屏蔽了很多C++的缺点，并加入了一些C++中亟待加入而又迟迟没人下手的东西。

Posted by: jiff | (53) March 1, 2007 04:11 PM

虽然 C/C++ 目前没有支持 gc ，但是每一个 C/C++ 程序员都应该深入了解一下 gc 。

从表层来说 gc 不等于智能指针， gc 不等于引用记数。

稍微深入一点，gc 的过程也是代码写出来的，每一个步骤都是可被程序员认识和控制的。

要坚持 C++ 可以没有 gc ，需要先看看不能没有 gc 的语言为什么会那样。只是一句“减轻程序员的负担”，那是哄小孩子的。

Posted by: Cloud | (52) March 1, 2007 01:04 PM

忘了说了
其实我个人也认为GC当作一个可选项加入C++是可行的，而不是只能GC管理内存…

Posted by: jiff | (51) March 1, 2007 10:11 AM

C++不是完全兼容C的么…越听越不明白了……
1。虽然C++的模板在很多时候被滥用了，但不至于说是如此大的罪过吧。毕竟template这个东西是个仁者见仁智者见智的东西。
2。云风说的GC的支持，这个更晕了乎了。C++之父在《C++语言的发展和演变》这本书里很清楚地解释了为什么不把GC加入C++的理由，其中最重要的几条是：
1.GC是比较耗时的。
2.GC算法会在一程度上阻止C++在实时系统中的应用，现在比较通用的GC算法都没解决实时回收问题，这等于是把C++的应用领域缩小了。
3.GC算法等于是帮助用户管理动态内存，这意味着用户不再有底层的控制权，这和C++用来也能做底层开发的想法不同。

Posted by: jiff | (50) March 1, 2007 10:09 AM

我们就是初学者，在计算机这个领域，我们又太多的东西要学习，从计算数学到硬件的设计，不可能拿天拍拍胸口说，我，达人了，如果有，可以和我联系，很荣幸能看到上帝了

Posted by: jeffery | (49) February 21, 2007 03:37 PM

虽然大家都在用C/C++，可都在各自的领域内做事，其实差别是相当大的。何必像个初学者那样在语言本生得层面上喋喋不休呢？讨论什么东西有意思？要么往上：数学/算法上，要么往下：编译器/硬件实现。

Posted by: kypck | (48) February 14, 2007 07:17 PM

说c++恶心的人是个白痴
我虽然也深陷于c++复杂性中，但是你们不得不承认，c++引入了很多拥有的概念和新的思路，如果你用不好这些东西，你大可以就只是使用那些你熟悉的东西，比如在嵌入式c++编程中，很多浪费资源的东西都不应用，c++没有使用好，只能说明你退步了，屈服去别人做好的东西，不断地禁锢自己.....

Posted by: jeffery | (47) February 14, 2007 06:55 PM

1)C++一样可以用全局变量把事情搞糟。

2）C语言一样可以不用全局变量。

在语法的层面，大部分C能够犯的错误，C++都有能力犯。

Posted by: zelor | (46) February 14, 2007 03:21 PM

用Ｃ的话那么多全局变量就不怕出什么意外？这时人的权力大了，有时没按规矩来，找个错误很难的

Posted by: Anonymous | (45) February 14, 2007 02:25 PM

那么多贴子都很空,只说自己怎么做,却说不出为什么要那么做

Posted by: Anonymous | (44) February 14, 2007 02:23 PM

线程和锁只是一种比较普遍的同步模型，
你完全可以换成其他模式，问题是，
无论什么模型，阻塞总是存在的，
正是这个因素导致了多进程或者多线
程的产生。

无论进程线程，都是操作系统
玩的花样。
同步是最终目的。

Posted by: zelor | (43) February 14, 2007 11:00 AM

当两个线程间没有共享数据的时候，它们就不再是“线程”，而是“进程”。
当两个线程间没有共享数据的时候，它们就不再需要“锁”，而需要“消息”。

Posted by: Atry | (42) February 13, 2007 08:58 PM

线程与锁是否可以避免应该说和底层是否阻塞有一定关系吧。

线程是可以避免的，但中断总在那里；锁也是可以避免的，但并发总在那里。

Posted by: zelor | (41) February 13, 2007 04:08 PM

线程和锁是可以避免的

Posted by: Atry | (40) February 13, 2007 02:17 PM

自己发明轮子，重写若干基础数据结构，确实可以提供代码的性能，STL开发那会还没有多核CPU，现在应该重写，作客户端用用STL无所谓的，服务器对于关键的容器采用自己开发个人感觉是完全可行的，也是有必要的。

Posted by: sunway | (39) February 13, 2007 12:32 PM

完善的文档和简明的架构才能保证代码的可维护性，用什么语言开发并不是关键，个人感觉。

Posted by: sunway | (38) February 13, 2007 12:30 PM

在我看来，制造轮子并没有什么奇怪。

STL由于缺乏对线程和锁的抽象，所以无法在数据结构一级实现线程安全。因此这个轮子基本是必须的。

RTL一般来说是通用性很好的，但未必是最适合自己项目的，所以较大规模的项目一般都要实现（部分实现）自己的RTL。

这些轮子从头造，看似浪费时间，实则如我一个同事的名言：慢就是快，快就是慢。

Posted by: zelor | (37) February 13, 2007 10:29 AM

虽然我喜欢“玩”C++，但是云风说的是对的。side effect是副作用的意思吧？的确一针见血。

我承认C++带来很多问题，但是也不能否认C++解决了一些问题，到底C++带来的问题更多还是解决的问题更多呢？

Posted by: Anonymous | (36) February 12, 2007 08:08 PM

我们现在的项目，我个人的贡献代码略小于 50% 。最近的 C 接口的设计等都不是我完成的。所以我不把它看成“我的”代码，而是“我们的”代码。

05 年的下半年，我做了最初的设计，但是接下来的工作大多不是我独自完成的。所以有理由认为这个项目是可维护的。

Posted by: Cloud | (35) February 12, 2007 06:28 PM

自己的代码自己最熟悉，当然不会觉得有什么维护上的困难，可能云风是觉得自己重头制造轮子很爽，可是这要增加多少开发时间和成本？新人接手要增加多少学习成本？又给项目增加了多少机会成本？

C++的一个设计初衷是为了增加代码的复用性，虽然事实上C++的复用性并不好，但是也没必要反其道而行。

Posted by: analyst | (34) February 12, 2007 06:04 PM

看来大家都喜欢高屋建瓴。。。

Posted by: sunway | (33) February 12, 2007 04:29 PM

to analyst, 我觉得我们目前的项目是比较好维护的，在你眼中的病态用法，正是我们对 C++ 裁减的结果。

而所谓 stl 这样的东西，并不是 C++ 的设计初衷。它只是后期加到 C++ 标准中的而已。

C++ 的设计初衷，并不包括 stl ，也没有 exception 、namespace ……

Posted by: Cloud | (32) February 12, 2007 03:45 PM

>我们的项目前期用 C++ 设计的框架，没有用任何 stl ，任何第三方类库，甚至没有用 CRT 。

嘿嘿，难怪云风会觉得C++不好用了，如此病态的C++用法已经完全背离了C++的设计初衷。

Posted by: analyst | (31) February 12, 2007 03:37 PM

看了这贴，我有点明白Bjarne Stroustrup为什么说“我不比较语言”了

Posted by: nothanks | (30) February 12, 2007 01:58 PM

就像在船上生活久了的人会在陆地上反而会晕一样。习惯了C自然不适应C++的风格。<br />
单就开发效率而言，解释型的语言效率更高。因为解释型的语言实现所受的限制小，更容易设计得易学易懂。但用惯了C/C++这类编译型的人看Python，Ruby未必不会觉得恶心。<br />
其实没有什么所谓的滥用，一种东西用得多或者少完全看你自己的能力和项目的需要。<br />
云风的确做了很多事情，可我们看到的有多少呢。说句不太中听的话。我觉得现在的云风远没有以前开放风魂时候的可亲可敬了。

Posted by: zotin | (29) February 12, 2007 12:27 PM

模板也不恶心呀。像AGG这样的项目。模板用的非常好，设计的非常棒。代码也很容易看。用不好的是功力不够

Posted by: liang | (28) February 12, 2007 08:46 AM

开源项目用C++几乎等于自杀.

Posted by: Shawn | (27) February 12, 2007 02:25 AM

C++ 相比 C ，代码可能带来的 side effect 太多了。几乎每个新特性都会增加 side effect 的可能性。

而 C 里面避免 side effect ，只需要避免全局变量的使用。

这或许是 C++ 代码难以维护的根源 (IMHO)

Posted by: Cloud | (26) February 11, 2007 05:29 PM

如果只是为了减少键击数量，C++ 是可以比 C 好很多。

但是影响开发效率的并不是键击数。

在开源社区里，成熟的 C 库比 C++ 库要多的多，不是没有道理的。

同样 10w 行代码，我宁可维护 C 版本，也不愿意维护 C++ 版本。如果必须达到 100w 的规模，我想 C++ 版本就不再只是头痛了。

我们的项目前期用 C++ 设计的框架，没有用任何 stl ，任何第三方类库，甚至没有用 CRT 。就是说，可以用任何一个 C++ 编译器，不需要任何标准头文件和标准库文件就可以 build 出来了。

因为最近几个月反省过，所以现在逐步修改成纯 C 来开发了。btw, 这个工作不是我来做的，因为我不太喜欢在 C 中用太多的宏。但我的同事觉得值得。为了兼容以前的 C++ 接口规范，所以用了许多宏来实现。

服务器部分是这半年才写的，已经改成纯 C 来设计了，结果感觉好了很多。

Posted by: Cloud | (25) February 11, 2007 05:22 PM

对C++比较熟悉.
觉得它是过度设计(这个问题不大),
也被过度使用了.

Posted by: mike | (24) February 11, 2007 02:43 PM

代码超过10W行用C开发过于痛苦？

我现在维护超过100W行C代码的项目，也没觉得有多么痛苦。估计换成写得好的C++也不会，只是C++被写坏的概率太高了。

Posted by: zelor | (23) February 11, 2007 02:30 PM

与云风兄感同。

做了几年C开发之后,对C++越来越不敢恭维。尽管当年是狂热的C++信徒。

Posted by: zelor | (22) February 11, 2007 02:16 PM

建议贴点代码出来看看，讨论讨论，毕竟都是同行，花点心思值得的

Posted by: Anonymous | (21) February 11, 2007 12:22 AM

我首先认为你这个项目估计可能是个服务引擎部分，ＧＣ这种东东需要语言支持吗？那用ＪＡＶＡ！现在人工要比硬件贵的多，不然当然理所当然自己搞，毕竟是低层的东东，花点心思搞好很正常，一个游戏项目里真正代码多容易出错的地方主要还是游戏逻辑部分，这些地方用脚本，引擎部分首先保证接口都是非常合理的，功能都正常，具有良好的扩展性，就够了，执行速度不是最重要，硬件比软件发展快的多．

Posted by: Anonymous | (20) February 11, 2007 12:20 AM

想想看，Ｃ＋＋的出现是为了什么，就是当代码超过１０Ｗ行时，就是长期的Ｃ程序开发大型项目过于痛苦，人们想找出一种可以提高软件开发速度，减少风险，使得程序员把注意力放在值得注意的概念上，即使经验不丰富的程序员也能相对保持一种较好的开发风格，云风认为Ｃ＋＋不如Ｃ，你认为前人的努力，这么多年白来的吗．如果是对效率要求很高的情况，硬件相对较弱的情况，用Ｃ很正常，比如单片机，但游戏项目会出现Ｃ＋＋不如Ｃ的情况吗，难道你一点Ｃ＋＋的东东都不用，ＳＴＬ，任何类库都不用？字符串用数组？不敢想像

Posted by: Anonymous | (19) February 11, 2007 12:11 AM

嘿嘿，我认为这是因为云风C++使用不当所致，namespace嵌套较多本来就是个忌讳，template滥用也是大忌，一味的追求设计的完美也是偏执的表现。

对多数人而言写程序的目的本来只是为完成功能而服务，高级语言出现的目标就是为了降低开发的成本，而很多人却本末倒置，C++发展后期出现的大量花哨语法和特性让很多人对语言本身产生了狂热，以至投入大量的精力浪费极大的成本去追求语言本身，例如构造天书般难读N层嵌套模板、构造复杂无比的N层继承树类库，当狂热过后蓦然回首才发现这一切都只是虚妄，软件开发效率的核心矛盾根本没有得到丝毫解决。

其实C++也可以有很多朴素的用法，使用得当还是可以显著提高软件生产力。对OO、GP、Exception等特性的良好支持依然是它比C可爱的地方，用的好可以节省很多的时间和代码量。你说没有GC的OO不完美，那么你可以妥协一下用引用计数，OO在细粒度的软件模块划分上还是占有主导地位；对于GP老老实实的用STL容器就可以了，algorithm就不要用了，没有closure的支持algorithm根本不实用，至于boost就看都不要去看了；Exception在错误处理上的优势还是很明显，相比较错误返回值可以节省一大半的代码量，当然也要付出一定的代价。其他方面C++还提供了很多的语法糖，例如RAII、智能指针等等，帮助你减少代码量和出错机会。

Posted by: analyst | (18) February 10, 2007 08:32 PM

郁闷，1.23号买的你的书,到今天才寄到.而且书看起来还不是全新的,再也不想去第二书店买书了.呵,看了点,果然有蛮多错别字...

Posted by: 锋寒 | (17) February 10, 2007 03:54 PM

test

Posted by: Anonymous | (16) February 10, 2007 03:05 PM

从我们现在的项目来看（几十万行代码，几百个源文件），C 语言写的模块更容易和人协作。

namespace 这个东西在面向接口编程时就无关紧要了。类的复用性比 c api 要弱的多，而加上 namespace 后更是如此。

用前缀后缀解决问题本来就不是个特别好的方案。C 里用的时候就会谨慎。而在 C++ 有了 namespace 后就好象在木头架子上硬去糊一层混凝土。没有钢筋迟早会塌掉的。

Posted by: Cloud | (15) February 10, 2007 03:03 PM

归根结底，还是个教育问题。家庭、学校和社会没把这孩子教育好。就像一个卖油饼的，他可以把他的油饼煎得很好，甚至煎得很有创意，也可以籍此谋生甚至可以很富裕。但是如果他受到的教育只是偏废煎饼这一单项技能，而不是把他作为一个人来全面教育，那他永远不知道世界是怎样的，对他来说人生的真谛就是油饼，他永远只会用油饼眼光来看世界。

Posted by: Anonymous | (14) February 10, 2007 10:19 AM

沾沾自喜，不值一提

Posted by: Anonymous | (13) February 10, 2007 01:25 AM

记得我刚入行时，一个高手和我说引用多么多么不好，多么多么容易出错，其实是语言功能多了，复杂了，容易出错和需要知道的细节多了，不过我们是游戏程序员，我们需要知道真像，抱怨语言的特性让自己务入歧途吗？我相信一切都是滥用造成的.

Posted by: Anonymous | (12) February 10, 2007 01:24 AM

我不认为编程有什么艺术可言，让电脑做事的方法而已，所谓的恶心多半是滥用引起的，但很多概念或模式大多刚开始是从一些语言中学到的,语言就是语言，工具而已，达到目地的手段而已，无所谓热不热爱,快速的稳定的有保证的让工作完成，对项目的控制力和把握力，才是最重要的，就游戏项目项言，引擎低层随你怎么搞好，你是高手，你能保证就好，但你走了，以后维护的人看你那堆Ｃ代码估计可能想哭，不如用ＡＳＭ好了，只要自己能控制，怎么样都行．多人合作写那种代码，我暂时想象不出来，麻烦你稍稍举点列子，说说你们现在的工作方式，就以上这几句话，我感觉你已经达到一种急度自恋的境界，我想看一些更有说服力的文章，而不是夸夸其谈，好的程序员应该是务实的!

Posted by: Anonymous | (11) February 10, 2007 01:16 AM

言重了罢...我无法评判什么,只是觉得可能大部分人现在再翻开云风的那本书，看到那些对C++的褒奖之词都会像我一样,起一身的鸡皮疙瘩

Posted by: nothanks | (10) February 9, 2007 11:30 PM

我用 c++ 只用做面向接口编程
1. 概念抽象
2. 接口设计
其它用 c 写.

如果都用 c, 多人协作的时候是个痛苦的过程

Posted by: KxjIron | (9) February 9, 2007 09:41 PM

呵呵，其实C语言还有很多特性也不太好，但是对于一种低级语言来说，那是必要的。

我不去指责C语言强制转换的void* ，C语言的fans也别指责别人用用模板。大家半斤八两，呵呵。

Posted by: Atry | (8) February 9, 2007 09:36 PM

恰恰相反的是，这半年来我玩C++却玩出了点感情。在我尝试过一些C之后，我总结出C的四个重大缺陷，这四点造成的负面影响也或多或少的一遗留了C++中：

1、\0结束的字符串。Unicode之所以会和ANSI不兼容，根源就在这里。大量的程序中的缓冲溢出的致命漏洞也都是因为这个。C++靠std::string解决了这个问题。

2、缺乏namespace导致命名的前缀后缀泛滥。因而C语言变得冗长，就不可能做到自描述。而C++支持namespace。

3、宏。所幸有了内联函数和模板，宏的使用范围已经很窄了。

4、编译时的头文件。靠一个连接程序根据头文件声明的名字去找符号是很不方便的，更大的问题是头文件极大地增加了模块间的耦合。这一点遗留到了C++，因为类和模板的存在，危害程度甚至更加变本加厉。但本质上说，这是头文件带来的，现在已经有支持分离模式编译模板的C++编译器，这证明模板本身是可以生成封装完好的二进制接口的（只不过“目前”大多数的编译器不行而已）。

Posted by: Atry | (7) February 9, 2007 09:23 PM

东西摆在那里给你用，用不用是你自己的事情，没人强迫，你自己用完了觉得恶心，那是你自己的问题，不要归结到语言上。每种语言都有它自己的使用范围，就像用j2ee写桌面应用一样，你可以那么做，但是可能很恶心人，但是它的长处还是在网络。

以前觉得你很了不起，甚至有些崇拜。但是近几年看着你在不断的改变，说话的方式，看待事物的态度渐渐令我感到恶心了。

Posted by: Anonymous | (6) February 9, 2007 09:18 PM

我倒不认为C++的模板有什么问题，反而是C++半生不熟的继承和半生不熟的内存分配才是问题

Posted by: Atry | (5) February 9, 2007 08:59 PM

试试不用继承，在外面做一个小模块实现扩展的功能。

Posted by: Atry | (4) February 9, 2007 08:58 PM

我觉得perl里的$@%很好啊？用惯了看不带前缀的C变量还不习惯呢

Posted by: mach | (3) February 9, 2007 08:50 PM

我以前也很热爱C++, 不过最近半年了，我大部分时间是用C写程序，现在再看C++也没有以前那么热爱了。不过它还没让我开始讨厌，我还是比较喜欢它的。

不知云风对C＋＋的厌恶由何而来？C++可能是有些令人讨厌的特性，但并没有强迫人们去用这些特性。不像python里的tabs和perl里的$@%等，你非用不可，这才叫人恶心，呵呵。