引用计数错在哪里？

刚才看云风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，根本不会因为有了构造和析构就让我们的服务程序动弹不得。

第五，用一个线程来定期扫描所有对象，无论从空间还是时间上都是浪费，如果一个对象自己能记住自己被引用了多少次，它就没有必要让另一个管理器来管理它。

那么，引用计数错在哪里？