c++ - 为什么 C++ 不能有一个可选的透明垃圾收集器

Question

有一个相关问题，但这个问题略有不同，我对相关问题的任何答案都不满意 :)

我将通过断言不可能为 C++ 提供可选的透明垃圾收集器来否定地问这个问题，并希望有人能证明我错了。是的，Stroustrup 尝试了这个并且多次失败，不是因为技术问题而是因为一致性问题。性能在这里不是问题。

C++ 永远不会有这样一个收集器的原因是，作为可选的程序，在没有收集器的情况下运行必须手动实现所有必需的内存管理。添加收集器可能会提供一些性能优势，但尚不清楚它们是否值得(是的，收集器可以更快)。

您无法获得的是自动内存管理，这是需要收集器的主要原因。您将通过强制收集获得此信息(如果您选择进行正确的手动管理，则不一定牺牲 RAII 或其他内容)。具有可选手动内存管理的强制收集器是可行的。

不幸的是，获得强制收集器的唯一方法与不使用收集器的早期版本的 C++ 不兼容:换句话说，如果我们想要自动透明内存管理，我们必须定义一种新语言。

所以我的论点是:C++ 永远不会有垃圾收集，因为它被锁定在需要向上兼容性的历史发展中:强制收集和可选的手动内存管理是可行的，但透明的可选垃圾收集不是。

通过展示一个可行的可选透明垃圾收集模型来证明我错了!

编辑:

Ooo .. 我想我找到了答案。有人可以在要求程序删除堆分配对象的地方引用标准吗？

因为:该子句(如果存在)是唯一停止可选透明垃圾收集的东西。甚至可能有足够的时间从 C++1x 中删除该子句。

如果没有这样的子句，程序可能会泄漏内存而不会出现未定义的行为:内存不足时的行为与通常情况下的行为相同。因此，添加垃圾收集器对指定的语义没有任何影响:它们是否定义良好，与是否使用收集器无关。

Answer 1

Prove me wrong by exhibiting a tenable optional transparent garbage collection model!

参见:C++/CLI .

将垃圾收集器与现有的 C++ 代码放在一起的困难在于，C++ 通常依赖于确定性的对象销毁来使事情发生；就像在 RAII 中所做的那样。当然，垃圾收集器能够使大多数类型的内存 RAII 透明，但是很多 RAII 相关概念与内存没有任何关系。例如，套接字、流和锁都适用于某种形式的 RAII 管理，如果不保留确定性破坏，这些都不会很好地工作。

因此，它可能不会是“透明的”——它必须是类似于 C++/CLI 的东西，你必须说“我希望它被垃圾收集”——但它无论如何都是合理且可能。