推推C语言新书《狂人C-程序员入门必备》

http://product.dangdang.com/product.aspx?product_id=20974009

http://www.china-pub.com/54010

《狂人C》在CU上的意见贴:http://bbs.chinaunix.net /thread-1821644-1-1.html

今天上午收到快递,收到键盘农夫的大作《狂人C》。首先要感谢国家,也要感谢键盘农夫给我这个机会拜读他的大作。

这本书拿在手里很厚实,翻了翻目录以及章节内容,不是那种教科书死板的风格,用词摘句很平实,感觉键盘农夫应该是有实际编程的经验才能写出这样的书。我在前面推荐的C语言教学,里面只包含了《Linux C编程》这本是国人著作。想不到现在还有人愿意静下心,写一本有价值的C语言专著,非常佩服!

草草看了一下内容,感觉值得改进的地方有这样几点(希望农夫不要见怪哦):

一是英文字体选的不好,看上去很不舒服。另外代码字体与正文中的英文字体差别太大。字体的选择对于程序员来说其实不是小事。另外中文字体的间距感觉也不是很合适,有些别扭。还有一点是边界留的太窄,很难做笔记(当然,留的宽了也会增加页数成本,唉)。

第二点是变量名的选择,键盘农夫应该是针对这个问题有所考虑,选择了拼音首字母作为变量名或者函数名,但是我个人感觉这其实不是一个很好的选择,尤其是qiufqsm这种,很难直观的看出来。我个人觉得程序员必须要学英语用英语,文件名、变量名不要用中文或者拼音,其实读写简单的英文对于大多数程序员来说不是难题。

由于中文变量名的存在,后面tic-tac-toe的工程实例看的很费劲,因为非常不习惯这种风格。

第三点算是小问题,比如我倾向于使用“字符字面值”,“多维数组”这种翻译,而键盘农夫兄是另有选择,但是由于书中基本附带了英文原文,理解起来并不困难。还有就是指针这一章中,指针地址很多写的比较详细,但是感觉应该稍作说明(也许有,但是看的潦草没注意)这些地址仅仅是假设的。

第四点也不是大问题,就是练习题没答案,对于初学者来说,有答案对照,可能会帮助很大。当然也可以有一个网站提供答案,也是一个办法。

尽管吹毛求疵提了这些问题,但是要说的是,这本书写的还是很认真的,尤其是一些关键点,比如指针及数组的概念,用了大量篇幅来介绍,也体现了作者功力所在。建议各位C语言爱好者买一本读一读,一定会有所收获。我也会在将来把自己的读后感放上来分享。

关于C/C++内存管理一些乱讲

http://www.cnblogs.com/skynet/archive/2010/12/03/1895045.html 这篇博客最后写了5个规则,虽然简单,但是还是有些问题,在这里稍作说明。

【规则1用malloc或new申请内存之后,应该立即检查指针值是否为NULL。防止使用指针值为NULL的内存。

偶评:参考wiki百科针对malloc以及new的说明,对于C语言malloc方式,检查NULL是可以的,但是对于C++的new操作符(operator),检查NULL基本是无用的,因为C++有异常机制,new不成功就会抛异常std::bad_alloc,如何处理可参考 http://msdn.microsoft.com/en-us/library/kftdy56f%28v=VS.71%29.aspx

【规则2不要忘记为数组和动态内存赋初值。防止将未被初始化的内存作为右值使用。

偶评:初值的赋值操作也是要花时间的,C语言初始化一块内存memset的时候要注意用buffersize * sizeof(Object),而C++就更复杂了,比如构造函数,new的重载之类,要小心。

【规则3避免数组或指针的下标越界,特别要当心发生“多1”或者“少1”操作。

偶评:一般来讲多一少一运行时不会一定出错,比如微软编译器申请内存一般会比你指定的大一些,比如你申请10bytes,如char* p= malloc(10);,通常情况下操作p[10],p[11]啥的是没有问题的,所以会发生一些奇怪的现象,就是某些bug有人机器会出,有人就无法重现。

【规则4动态内存的申请与释放必须配对,防止内存泄漏。

偶评:要说明的是,new一定和delete配对,malloc一定和free配对,否则也会出错。另外new [],一定要delete [],否则也会泄露。

【规则5用free或delete释放了内存之后,立即将指针设置为NULL,防止产生“野指针”。

偶评:这种情况一般是代码中函数写的比较长,指针用了又用,或者指针是全局的情况。所以一般软件公司的编码规范都会硬性要求这样做,如果函数很短小精悍,其实不会有这种担忧的。当然,偶也同意这样做有益无害。

再加入一些额外的说明:

对于指针类型的检查,不应该用assert,而是应该正常操作,if(!p) return E_POINTER;这样。使用assert的语义与空指针判断是两码事。如果不想判断或者图省事,C++中可以用const reference类型,但是不建议传入reference对象,然后在函数体内修改。

针对内存操作,比如memset,memcpy,同样要注意不能访问越界的数据,类似规则3。

针对C++,new delete其实可以做出好多花样,个人感觉用处不大,因为服务器端编程大多用C配合内存池,重载new之类的学了也很少用。如果对服务器端内存管理感兴趣,可以读读nginx的代码,简洁高效实用。

一般来讲,应该是谁拉的屎谁擦屁股,也就是说某个对象或者函数new了一些东西,它应该负责delete,否则距离不仅仅产生美,还会产生bug。(多废话一下,比如在aaa.cpp里面new了一些东西,然后你在bbb.cpp里面释放它,甚至在不同地方释放它,如果对程序结构不了解,很容易产生bug)

可以通过python或者lua编写一些小软件,检查项目中new与delete,malloc与free的个数,如果个数不匹配,就有可能有bug,另外还可以检查new[]与delete[]的配对情况。我编写了一个这样的小工具,完善以后放出来。

有趣的Comet技术选择,论 Is node.js best for Comet?

首先要声明,我对Comet技术只了解皮毛,下面的评论如果有错误欢迎各位看官指出。本文相关博客地址:http://amix.dk/blog/post/19577#Is-node-js-best-for-Comet

amix在这篇博客中谈论他们在Plurk中Comet技术选择的变迁。

说句题外话,他有另外一篇博客
http://amix.dk/blog/post/19581#The-main-issue-with-non-blocking-servers
里面用两张图形象的介绍了阻塞式服务器与非阻塞式服务器的工作方式,感兴趣的可以去瞅瞅。amix关于node.js和v8的介绍可以看这里http://amix.dk/blog/post/19484#Comet-with-node-js-and-V8

关于Comet技术,可以参考维基百科 http://en.wikipedia.org/wiki/Comet_%28programming%29
国人有个开源项目http://code.google.com/p/eurasia/ 好像是做类似工作。

回到这篇博客上来,amix提到他们在项目中针对comet技术的选择,一开始是使用fast polling with C memcached nginx libevent,实现代码可以参考
http://amix.dk/blog/post/19414#Fast-polling-using-C-memcached-nginx-and-libevent
后来这个方案碰到局限了,不知什么局限,总之是不好用了。

于是实验了很多其它的comet方案,但是都不成熟。所以他们用Java与Netty实现一套comet方案,可以参考
http://amix.dk/blog/post/19456#Plurk-Comet-Handling-of-100-000-open-connections
文章里提到Twisted缺点是太耗CPU而且不易扩展;Jetty太耗内存;Tomcat也是很耗费内存;apache Mina文档不行,而且也不易扩展。最后选择了Netty,amix没有提到他们如何用Netty实现的,所以估计想用这个方案的朋友得单独联系他了。

后来amix发现node.js不错,他把java方案移植到nodejs上,只用了2天时间。在过去8个月(从2010年2月到10月)nodejs方案每天可以服务几百万用户的comet提醒。

但是,总有但是,随着网站用户增多,nodejs方案也碰到瓶颈了。即使试着做了一些优化和增加硬件,效果并不明显。amix他们又回到Netty方案,经过一些代码优化后,尽管内存使用量大于nodejs方案,但是性能要好于后者。Netty方案每秒可以为10000个客户端提供约6000个comet提醒,而Nodejs方案只能每秒服务500个,所以可以说新的Netty方案有10倍以上改进。

amix总结道,node.js是一个非常棒的方案,至少撑了8个月,而且实现起来也很快。但是nodejs有致命的缺陷。这个缺陷来自nodejs的基石-V8 JavaScript引擎。

V8引擎不支持线程或者进程机制-每件事都是主进程处理,甚至包括垃圾收集。

对于浏览器而已,这个限制是一个聪明的选择,大家知道每个Chrome页面就是一个单独的进程,所以V8引擎这种方案很好用。但是对于服务器架构就不一样了,这种单进程单线程的限制就变得麻烦。(具体为何麻烦我也不知道,也没写过nodejs项目)关于V8在服务器端使用的局限性,Nginx作者也有一篇博客介绍Why is Google V8 is not suitable for embedding in servers http://sysoev.ru/prog/v8.html 大家可以通过google翻译成英语阅读(翻译成中文后读起来很奇怪,还不如英语好懂),主要也是抱怨异常处理、进程模型、垃圾收集这几个方面。对于浏览器比较适合的V8方案,在服务器端就变成无法承受之重。

后面的回复也值得参考,其中有人提到使用nginx建立Nodejs集群然后分发,有人建议说重写nodejs的http模块很好用,也有人建议fugue这个方案http://github.com/pgte/fugue ,nodejs作者Ryan Dahl也留言说明前面版本某个bug可能导致性能问题。

偶个人的感想:即使amix有这样的抱怨,但可以看出nodejs依然是服务器端实现comet的很好选择,异步编程、高并发、低功耗,而且作者非常活跃,社区膨胀的非常快,个人感觉nodejs活跃度已经超过Lua。Lua社区有些程序员也试图用libevent或者libev来为Lua加上非阻塞异步服务器端编程的能量,但是影响力都不够,成熟度也不如nodejs。接下来偶会对nodejs做更多的探究,从源代码到小程序编写应用,希望能通过nodejs提高一下自己对服务器端编程的理解。