to pora:
没有不公平啦，那是后一个release测的，大家觉得还是硬件导致的比重大一点。另外我们的这种online service C++也不敢太关注效率，动不动就crash可不行，宁可慢一点的。反正bottleneck在DB和web service call.
to sjinny:
引用:
|
Elminster，你这两篇我也看过的，我对你的思路的理解是：对象生存期由程序员控制，内存由gc回收……干脆就放弃了对象和内存的绑定……那么用什么样的机制来保证对象生存期控制的正确性呢？手动析构对象和手动释放内存有同样的问题，要在何时的时机析构。析构过早，要么崩溃，要么抛异常。
|
那就看你要什么“保证”了。我觉得在实践上，你说的那些情况，基本不可能发生。即便发生了，因为内存还没有被回收，也不会导致很不良的后果。如果你愿意给每一个对象加一个bool _isDisposed的话也可以检查出来。但是要更进一步的严谨的保证的话，你需要为此付出很多代价的，比如写程序的便利性，效率等。不划算。为最后的20%质量可能付出80%的价格，这种奢侈品我可消费不起。
ref counter一看就很慢很浪费，和你一开始说内存小CPU贵矛盾。而且中间漏写/写错这些wrapper就会提前释放或者泄露。这可不是不会发生的事情啊，以前就碰到过，查了好久的说。
这个和你说的一样是“高确定性”和“自动化”的，但是代价却不小。要高效和要自动有的时候是矛盾的。