« 服务器消息的广播 | 返回首页 | 多进程的游戏服务器设计 »

假期好读书

又是一个长假,由于连着年度旅游,假期比往年更长一些。出去旅游前,就有同事嘲笑,“出去玩还背着那么厚一本书,累不累啊。”我自己知道,书是带回家看的。

这个假期伴随我的是这样一本书——《UNIX 编程艺术》。几个月以前就开始读了。以前是随手翻开中间几页读上一篇;这次,躺在阳台前的躺椅上,舒服的晒着阳光。终于,从头至尾的完成了。

贯穿始终的 KISS 原则,很多年前就被谆谆教导过了。它被我无时无刻的都拿出来警告自己的设计过程。读完这本书,让我对 KISS 又有了一次升华。其实,这本书对我几个月来设计游戏服务器架构的影响是满大的。坚定了我每写一个程序做好一件事的决心。让我更确信用多进程的设计取代多线程的决定是正确的;我们坚持的二进制模块复用的模型是切合 SPOT 原则的。

回顾自己对 C++ ,逐步的敬而远之,并非因为读了这本书。这本书基本没谈 C++ ,但是只言片语却深合我心。书中对 C++ 的不屑,于我看来并非如我曾经读过的某些书评所述:来源于作者对 C++ 了解的肤浅。

我自己仍旧对 C++ 充满兴趣,并继续努力对 C++ 做最大的理解,其实正是为了可以压抑住在项目中使用它的念头。这是我最近一年来编程思想最大的转变。同时,身边的人也受到了这种影响并慢慢接受。我相信,我们的方向是正确的。

Comments

当初创造出C++的人,或者创造出其他那些为了解决问题的语言的人们,应该没想到有人会为了使用A语言或者B+语言或者什么C++语言闹得不可开交吧? 问:秦始皇和毛泽东对人类发展史的贡献谁更大? 无聊。
为什么讨论的最终总是跑到编程语言的钉子上?!能不能再无聊一点?!
楼下的兄弟,你引用的帖子是sunway同学发的。。。 我看了之后就觉得不是Atry说的。后来一看,果然不是。
Posted by: Atry | (5) October 7, 2006 11:02 PM >>让我更确信用多进程的设计取代多线程的决定是正确的; 这个我表示反对,现在的趋势都是多核CPU,INTEL和AMD在各种场合都提到多线程技术是充分利用多核CPU性能的开发手段,因此多线程技术是以后程序开发必须的手段,尤其是对于性能要求比较的服务器端开发。 时代再变,我们的开发观念也应该改变。 ------------------------ 其实两种情况的适用范围是不一样的,ERD可能没有强调,但不能不明白这一点。 呵呵 atry兄弟 可能关注的领域和云风不一样,梦幻西游的服务端如果使用win32 和多线程,我相信不会有今天的163 我们有项目(2千万用户数量级)使用了多线程,C++,OO,20万行+的代码,程序每天吊死一次,查不出来原因。HP-UX下,POSIX线程本身就有问题,HP还来人给打了补丁
人类一思考,上帝就发笑。
很是无聊的流浪者
还有经常有人说指针是不安全的东西,建议不要使用。 的确,指针是不安全,但你做底层开发,比如用汇编,哪个又是彻底的安全呢??重要的是你要安全的使用不安全的东西,而不是选择逃避!!
还有经常有人说指针是不安全的东西,建议不要使用。 的确,指针是不安全,但你做底层开发,比如用汇编,哪个又是彻底的安全呢??重要的是你要安全的使用不安全的东西,而不是选择逃避!!
学过VB C# C++, 觉得C++太美妙了,只有你想不到的,没有C++做不到的, 真正程序员的语言 C++
我看了你的游戏编程的书籍,看完后我觉得要好好学习C++。当我学习C++时,我又发现C是很重要的,当我学习C时,我又发现ASSMEBLY LANGUAGE的重要性,于是我又看完了IBM ASSEMBLY LANGUAGE AND PROGRAMING,C PRIMER PLUS,C++ PRIMER PLUS。呵呵,忽然感觉是你那本书让我明白了许多。
我买过你的一本书,呵呵. 感觉你的思想非常成熟. 希望中国多有几个象你这种人/:)
我也最近也开始尝试学习Lua,觉得比起以前学C++的时候困难多了,一直宣称小巧易用的Lua为什么会这么难学。对于Python,《Dive Into Python》只看了一章就看不下去了。-_-b 现在是觉得,相比用C来写代码,如果规模稍微大一点,就感觉组织起来很力不从心,用C++就觉得要好过很多。唉,也许就是因为功力不够吧。但这反过来也说明什么问题呢,相信像我这种情况的,不止我一人吧,哈哈!
不过这本书所说的“序列化、协议形式的接口”的确很牛,让我感觉到摸到设计接口的正确方向了
这本书对于面向对象采取不屑的态度,我猜想这本书中所指的“面向对象”可能是MFC那种面向对象。而不是指的java那种面向接口
笔者编写了一个类似c#的静态完全强类型的脚本语言csm,当然目前还在不断完善中.欢迎大家指正.网址是csm.zg66.com.
倒,这样的书你可以看进去。。。真是爱好啊。 要是我,哼哼。。
一直只用C++,因为我做的是电话接入程序,性能要求比较高。对vb,java略知皮毛。近来学lua,python,感觉比C++难多了。想大学时抱着一本砖头厚的C++教程也没感觉怎么费力,反而觉的很过瘾,现在看脚本倒觉得不太容易理解,不知道是先入为主的原因还是自己理解力有问题。C/C++接近机器模型,觉得更容易学习理解,脚本语言试图达到人自然可读的状态,但以现在的计算机科学发展的水平,似乎在可预见的未来无法实现。
呵呵,按云风的影响力,这篇小小的blog搞不好又带来一次语言大战,唉...
What kind of programming languages do you think will be mostly used in future- languages like Visual Basic (easy to create applications), or languages like C++ (hard to create applications, but very powerful)? All these languages will have their place, and none will “win out over the others. Programmers who buy into the .NET vision will use mostly C# and VB.NET. Programmers who write traditional Windows apps will still use VB and C++. And UNIX folks will favor C, C++, and Java for a long time.
摘抄网上Jeff prosise(programming windows in MFC 的作者)的话: 记者问: What is the future of C++ comparing with Java and C#? What is the future of C++ Job market? If the market will still exist , what is the important technique? Pattern? Generic progamming and STL? COM? something else? 回答: C++ will be around for a long time. It’ll be used forever by embedded systems programmers and progammers who write traditional kinds of apps. But for those of us who write Web apps, C++ will become an anachronism.
不管如何,C++仍然是游戏开发的主流语言. 只举失败的例子,为什么没举其他例子? 例如用C++ 写的: JPL火星漫步者自动驱动系统、MAN B&W巨型船用柴油机引擎控制系统、高度分布式系统的ICE下层构造 等等... C++ 的复杂来源三个地方:与C的兼容, 静态类型检查, 高性能. 导致类库统一的缺乏, 再加上 internet 的普及. C++的项目失败率高,我怎么没觉得呢?那么多游戏怎么出来的,话回过来说,就算真的是失败率高,那么这些人他就是"没有领悟"C++的精髓.或者"不适合"做C++的开发. C++很大很大部分,是要靠"悟"出来的,说难听点,心智不成熟的人,很大程度是"悟"不出来的.不是说人坏话,至少我认识的圈子里面的C++程序员都这么认为. 该怎么用还怎么用吧,啥舒服用啥.
哈,用不着那么激动,别从字眼上理解,帖一个2005年的统计: 1 C 20.709% +2.11% A 2 Java 17.478% -6.09% A 3 C++ 11.927% -4.16% A 4 PHP 9.482% +3.17% A 5 (Visual) Basic 7.928% -0.62% A 6 Perl 7.461% -2.14% A 7 SQL 3.314% +0.22% A 8 Python 2.842% +1.72% A 9 Delphi/Kylix 2.572% +1.77% A 10 C# 2.203% +0.40% A 11 JavaScript 1.703% -0.04% A 12 SAS 1.412% +0.63% A 13 COBOL 1.068% +0.31% A 14 ABAP 0.736% +0.50% A- C++导致项目复杂度增加已经是公认的了,C++就是本来10行写得完的程序,非要用30行来完成,并自称“封装”,但每每到第二个项目的时候却将80%打破重写,并美其名曰“重构”。 就像我之前说的波音公司,只是举个例子,C++的项目失败率太高了,如果说这些人都是“没有领悟”C++精神的话,那只能说C++本身就出了问题。 国外C++都开始没落了,就国内用的人还那么多。
C++编译速度比C慢是否就是因为二进制耦合的关系呢? C语言里面只有extern的变量才会增加二进制耦合,其他需要隐藏变量的可以放到file scope,而C++的类的每一个成员都会增加二进制耦合。C语言的结构改变虽然也会导致调用者重新编译,但是C语言的结构就是接口的一部分,接口改变,调用代码当然应该改变。但是C++的类声明中的非公开成员,以及公开成员中给库内部使用的,都不应该是接口的一部分,而修改他们却会导致调用者重新编译,这个二进制耦合就导致编译速度慢。 所以,在C语言中,.h就是一个接口描述文件。然而,C++的.h文件却不是一个接口描述文件,它涉及了实现!! 这就是为什么我们必须要把一个C++的类从一个虚基类派生,然后用工厂方法来构造而不是构造函数的缘故。构造函数允许在栈上分配内存,这就要求调用方必须知道实现细节。 必须要说的是,这种要求并不是面向对象本身要求的,纯虚类作为一个接口的确有利于接口和实现的分离,但是当类的公开成员本身就等于接口的时候,这个类并不需要对不同的调用者表现出不同的接口的时候,使用纯虚类做接口不是必须的。 .net和java的库里,有一些小对象并没有实现任何额外的接口(此处的接口指java语言中接口而非上面所用的泛指的接口),他们的类声明本身就是接口。 .net和java可以这样做而仍然保持高速编译的原因是因为他们的对象分配是由虚拟机来管理的,调用者即使new 一个对象也不需要知道对象的实现。然而,C++做不到,C++抛弃了C语言以文件包含来处理耦合的做法,但是抛弃的不彻底。C++加入了public,private和protected,但是那只是骗骗编译器而已。private的语义就是你不应该知道的隐私,但是你若真的不知道,你就无法通过编译!!!
我也读了,虽然尚未读完,不过确信其中精华的章节已经研读过了. 偶也用C++,但是并不会因为读过此书而不用C++,而要继续使用,并且在某些设计层面上更谨慎,才不至于落入陷阱之中
突然想愤青一下,别见怪,哈哈。 笑话一:C++是一门不吉祥的语言,波音公司之前用ADA为飞机硬件编程,一直用的好好的,后来换成C++飞机就坠毁了。 >有一个人穿着黄色的衬衫出门没下雨,穿着红色的衬衫就下雨了,所以红色衬衫是不吉祥的衬衫,这显然是胡扯! 笑话二:什么是C++?C++就是本来10行写得完的程序,非要用30行来完成,并自称“封装”,但每每到第二个项目的时候却将80%打破重写。 > 什么不是C++? 不是C++就是本来可以用C++写10行可以完成的代码,一定要用封装来完成,固步自封者总认为这就是C++.可笑至极.至于打破重写,是设计问题,和语言有关系么? 笑话三:C++有太多地方可以让一个人表现自己“很聪明”,所以使用C++越久的人,约觉得自己“很聪明”结果步入陷阱都不知道。 > 不喜欢C++的人总是认为自己"更聪明",什么都可以自己做出来,所以鄙视C++的人,就觉得自己最牛B,其实是自己努力找罪受还乐在其中. 笑话四:C++其实是一门没有用途的语言,为什么unix下全是c?因为在unix下所有问题都有成熟的解决方案了,C++之所以活到今日,一是由于win写界面用C++,二是由于stl。 > unix 下全是C 那是因为历史原因,当时如果用pascal写的unix我相信现在满世界都是pascal了,C++的unix版本早就有了,没有听说或者名气不大的,并不代表"用C++写的系统不好". C++之所以活到今日,岂是汝辈所能理解? skywind是俺朋友,虽然是笑话四则,仍反驳一下,没有其他意思:-). 真正用C++的人是不会滥用C++的,而初学C++或者达到某一阶段的人正是因为碰了种种钉子之后而放弃继续的研究导致排斥现象. 而恰恰因为这样,C++的人才才会如此优秀.
这里的二进制耦合是否主要是对于对象字段的访问而不是函数和方法呢? 因为对方法来说DLL本身就可以解决。 而字段会影响到占用内存所以必须编译时解决。 统一的ABI的问题其实也不是问题,你不就解决了吗?就算解决不了,至少在同一个编译其下面是没有二进制耦合的。 所以我想,是不是只要能够把字段想办法隐藏起来就可以做到同一个编译器下没有二进制耦合,也就是说需要给调用方使用的.h文件只要接口不变就不用再修改,包括间接#include的文件也不会改变。
云风大哥,我想请教一下你是怎样看待二进制耦合的。怎么才算没有二进制耦合呢
怎么变成C++批判大会了 : D
你们都不用C++了么
懂了,是因为c++会让东西变复杂吧.
服务器端的任务会越来越复杂而把这些复杂的业务逻辑都独立成不同的进程来单独处理比在一个进程中开多线程处理效率要低。 1。进程间通讯的开销大于同一个进程内线程间通讯的开销。 2。进程消耗的系统资源大于进程内开线程消耗的系统资源。 现在ITNEL的编译器甚至能把一段代码优化成多线程执行。可见多线程在充分利用多核CPU方面是有优势的,要不然INTEL也不会这么做,毕竟INTEL是设计CPU的,他对多核CPU的了解远远超过我们。
让我更确信用多进程的设计取代多线程的决定是正确的; 这个我表示反对,现在的趋势都是多核CPU,INTEL和AMD在各种场合都提到多线程技术是充分利用多核CPU性能的开发手段,因此多线程技术是以后程序开发必须的手段,尤其是对于性能要求比较的服务器端开发。 时代再变,我们的开发观念也应该改变。 多进程不能利用多核CPU??? 多核一定需要多线程才能发挥威力吗?
劝各位C++的使用者迷途之返,不要固步自封,尽早悬崖勒马,否则后果不堪设想
突然想愤青一下,别见怪,哈哈。 笑话一:C++是一门不吉祥的语言, 波音公司之前用ADA为飞机硬件编程,一直用的好好的,后来换成C++飞机就坠毁了。 笑话二:什么是C++?C++就是本来10行写得完的程序,非要用30行来完成,并自称“封装”,但每每到第二个项目的时候却将80%打破重写。 笑话三:C++有太多地方可以让一个人表现自己“很聪明”,所以使用C++越久的人,约觉得自己“很聪明”结果步入陷阱都不知道。 笑话四:C++其实是一门没有用途的语言,为什么unix下全是c?因为在unix下所有问题都有成熟的解决方案了,C++之所以活到今日,一是由于win写界面用C++,二是由于stl。
hehe,C++很像玩具,可玩的地方太多了,有趣极了
>>让我更确信用多进程的设计取代多线程的决定是正确的; 这个我表示反对,现在的趋势都是多核CPU,INTEL和AMD在各种场合都提到多线程技术是充分利用多核CPU性能的开发手段,因此多线程技术是以后程序开发必须的手段,尤其是对于性能要求比较的服务器端开发。 时代再变,我们的开发观念也应该改变。
老夫夜观心象,C++阳寿快尽了
因为C++快寿终正寝了
为什么要'理解C++却不用C++'呢?

Post a comment

非这个主题相关的留言请到:留言本