引用:
作者: sjinny  终于有人回复了…… T.T
其实，我现在最想看到的是给gc揭短的文章，因为兜售gc的文章已经太多了……
其实，gc只是内存自动管理机制的一种，而且还带有很大的不确定性……桟就是一种自动机制，只不过它的生存期模型很特别，所以很多情况下表达能力不够。所以我想，也许可以思考其他的生存期模型，不一定是桟，而是其他的模型，但是确定性仍然要比较高……如果能有更多的像桟这样的确定型的自动模型，那么依靠它们的互补也许就可以做到在绝大多数情况下不需要使用gc这种高度不确定的模型了……
我很少看到文章从这个角度考虑问题。但是前几天搜索到一些论文，虽然也比较老，但是其中谈到了基于Regions的管理方法，其实就相当于内存池，但是是变成了一种语言特性。这是我所看到的唯一有点接近上面那个桟机制的思考角度的文章……
Elminster有什么看法不？ |
GC 的不确定性一般来说不是什么问题，除非你是在为战斗机写火控系统，必须有可证明的硬实时要求。现在研究其他内存管理机制的文章如此之少，其实也从一个侧面证明了 GC 作为一种通用的内存管理机制并没有遇到太多的麻烦。
引用:
作者: sjinny 如果某个语言没了gc就不能活，只能说明语言的设计出了问题：这个语言吊死在了gc这一棵树上。其实对于一下java和c++，java一直以“完全的面向对象”为宣传亮点，而C++的特点则是综合了多种不同的范式，包括面向过程、面向对象、GP等(说“等”是因为C++以后仍然可能继续添加新的范式)。其实java的所谓完全的面向对象，只不过是它的编程范式多样性匮乏的另一种说法，几乎是在把缺点当作优点来大肆炒作。C++09的gc也是程序员可以自己控制的，而不像java那样强加于人。java所缺乏的就是C++的包容性和对程序员的选择权的尊重。 |
没有 GC 不能活的语言很多，而且其中颇有一些是非常伟大的设计，比如 lisp 语言家族。
引用:
作者: sjinny 汗，好像扯远了……
总之，从语言设计的角度看，gc就是一个可以选择的东西。因为是否使用gc是针对具体应用进行分析时所作的选择，也许某些机械的事情程序员做得不如程序好，比如增加和减少refCount，但是是否使用gc这种决策，应该相信没有机器能做得比人好，也没有人能够在设计语言时就替别人做出选择。 |
GC 是不是一个可选项，取决于这个语言打算支持什么样的程序设计范式。如果打算支持函数式程序设计范式，那么 GC 就是必须的；同样的，书写面向对象程序的程序员如果能有 GC 的支持，也会舒服得多，能够应用更多可以提高生产力的技术。是否使用 GC 这种决策，确实没有机器能够比人做得好，不过设计语言的时候做出这个决策却一点问题也没有：虽然你不能决策这个语言是否内建 GC，但是你可以决策究竟使用哪种语言，不是么？