到现在“时刻”和“时机”都分不清楚……不知道具体“时刻”，但是直到“时机”，那么仍然可以进行控制，事实上绝大多数的情况下，知道的都是“时机”而不是“时刻”，只不过有的“时机”很容易实现（当挂电话时删除计费对象），有的“时机”很难实现（当最后一个指针不再指向自己时释放自己）……

gc的问题不在于它提供的功能，而在于实现方面所产生的限制。


我已经不打算继续在这里回帖了，这么多回帖没有任何收获。我愿意对自己的内容做进一步的解释，而别人不愿对自己的内容进行解释，那我只能说别人不愿花时间与我交流、分享知识，所以我不必继续这样下去了。既然在这里“诚意”不重要，那么这里不是我所寻找到地方。
道不同不相为谋

这种愤慨，似乎在很多被专业人员“高高在上”地无视的民间科学家那里表达过。

连google都懒得google，对基本专业知识都不屑一顾的，还是自己独自在科学的道路上披荆斩棘，作个孤独探索的勇士吧。

不如讨论一下“在有GC的环境增加显式的确定性内存管理之必要性”。

晕 第一次看确实没得到你的点~
我们那里说话都这个味道的说……

D不就是咯。

D 那个允许在 GC 堆上显式释放内存的方案根本就是扯淡。

很感兴趣，愿闻其详。

这个事情我们以前说过吧？一方面支持这个干扰 GC 的实现，另一方面显示释放了之后悬挂引用的问题又会冒出来，得不偿失啊得不偿失。

是啊 得不偿失。还不如另外维护一个手动堆呢。像C++/CLI一样。

这两个问题就是基本的gc和手工混合的难点吧？我自己就不知道怎么解决这个问题。但是既然D提出了这个功能，难道这两个难点一个也没解决？