Ytt*_*ill 3 c++ garbage-collection
有一个相关的问题,但这个有点不同,我对相关问题的任何答案都不满意:)
我将通过断言不可能为C++提供可选的透明垃圾收集器并希望有人证明我错了,从而对这个问题提出质疑.是的,Stroustrup尝试了这一点并且一再失败,不是因为技术问题,而是因为一致性问题.性能不是问题.
C++永远不会有这样一个收集器的原因是,在没有收集器的情况下运行的程序是可选的,必须手动实现所有必需的内存管理.添加收集器可能会带来一些性能优势,但不清楚它们是否值得(是的,收集器可以更快).
你无法获得的是自动内存管理,这是渴望收集器的主要原因.您可以通过强制收集获得此功能(如果您选择进行正确的手动管理,则无需牺牲RAII或其他内容).具有可选手动内存管理功能的强制收集器是可行的.
不幸的是,获得强制收集器的唯一方法是创建与不使用收集器的早期版本的C++不兼容:换句话说,如果我们想要自动透明内存管理,我们必须定义一种新语言.
所以我的论点是:C++永远不会有垃圾收集,因为它被锁定在需要向上兼容的历史开发中:强制收集和可选的手动内存管理是可行的,但透明的可选垃圾收集不是.
通过展示一个可选的透明垃圾收集模型证明我错了!
编辑:
噢..我想我有答案.有人可以引用标准,它需要程序删除堆分配的对象吗？
因为:该子句(如果存在)是唯一阻止可选透明垃圾收集的子句.甚至可能有足够的时间从C++ 1x中删除该子句.
如果没有这样的子句,程序可能会泄漏内存而不会出现未定义的行为:内存不足时的行为与通常情况相同.因此,对垃圾收集器执行操作将不会对指定的语义执行任何操作:它们是否定义良好,与是否使用收集器无关.
Bil*_*eal 11
通过展示一个可选的透明垃圾收集模型证明我错了!
请参阅:C++/CLI.
将垃圾收集器与现有C++代码放在一起的困难在于C++通常依赖于确定性对象破坏以使事情发生; 正如在RAII中所做的那样.当然,垃圾收集器能够使大多数类型的内存RAII透明,但是大量与RAII相关的概念与内存无关.例如,套接字,流和锁都适用于某种形式的RAII管理,如果不保留确定性破坏,这些都不会很好.
因此,它可能不会是"透明的" - 它必须是像C++/CLI这样的东西,你必须说"我希望这是垃圾收集" - 但它绝对是合理和可能的.
这可能更适合作为评论而不是答案,并且可能会引起许多暗示.就这样吧.
每当有人问"为什么C++不能使用GC？"这样的问题时.我想我自己"因为我不想要你那个该死的垃圾收集.我想控制物体何时存在.我想控制物体何时死亡.我希望破坏和解除分配是确定性的,而不是基于一些hokus pokus黑魔法.我不需要GC来编写更好的程序.因此,GC对我没有任何作用,但会妨碍我."
但即便如此,请考虑这一点.C#和其他.NET语言都内置了GC.这些语言的编译器和CLR主要是用C++编写的.这包括内存管理工具,除了一些用汇编语言编写的性能关键部分.
所以你可能会说C#可以做的任何事情,C++都可以做,因为C++生成C#.
继续,向下走