刚才看云风BLOG中《对象和资源的管理》(Trackback地址:http://blog.codingnow.com/mt/mt-tb.cgi/140),颇有不同意见。
首先,C++不是C#不是Java,如果非要在C++里专门开一个线程来搞GC,那不如不用C++。C++程序员可以精确控制对象释放的时机,这正是C++的长处,比方说,我有一个Socket对象,我可以保证在析构的时候就Close这个套接字,但在C#里,很痛苦地不能这么做,因为鬼才知道这个对象什么时候才销毁。
第二,怕忘记减少引用计数吗?文中自己也承认C++的语法可以完美地让你在引用一个对象时,自动递增计数,而在不需要它的时候递减,即然有这么好的语法,为什么不用呢?难道编译器会比程序员(人)更易犯错误吗?
第三,原文中说“可以在主线程中安排一个定期时间,扫描所有对象,把需要删除的对象删除。而平时的删除,只是做一个简单的 mark 操作”,那么,谁来做这个mark操作,比方说,我在一个stl容器中放了一个对象的指针,在该stl容器被销毁的时候,它敢mark吗?它如何知道没有人在引用这个对象呢?这个mark和delete又有什么区别呢?
第四,原文中似乎没有地方能证明出“靠编译器(自动)生成的代码来保证引用计数正确”这种做法的不合理性,仅仅是说编译器隐式地生成了一些代码(目标代码多了)。这个是理由吗?现代语言要做的就是让编译器完成更多的事情,让程序员少犯错。难道相比之下,我们宁原愿意让源代码量增加(且易出错)吗?想起一份统计文档,说Perl的一行代码相当于6行C代码所能干的事情,而一行C++代码的大约相当于2.5行C代码,也就是说,越是高级的语言,它的源码量就越少,这是天经地义的,至少说他会生成多少目标代码,这个不应该是考虑的事情吧,而且C++生成的代码的效率很接近C,根本不会因为有了构造和析构就让我们的服务程序动弹不得。
第五,用一个线程来定期扫描所有对象,无论从空间还是时间上都是浪费,如果一个对象自己能记住自己被引用了多少次,它就没有必要让另一个管理器来管理它。
那么,引用计数错在哪里?