主流C++编译器中 GC 实现的时间线是什么？

你有点误解了。

C++11 支持与 GC 更好地集成，这要归功于一些关键功能，可帮助他们更好地分析哪些是可访问的，哪些是不可访问的。如果您检查新的<memory>标题，您会注意到：

• declare_reachable：声明对象不能回收
• undeclare_reachable：声明对象可以回收
• declare_no_pointers：声明内存区域不包含可跟踪的指针
• undeclare_no_pointers：取消 std：:d eclare_no_pointers 的效果

然而，这并不意味着 C++11 建议使用 GC 或推送编译器来集成 GC。

如Boehm-Demers-Weiser的指导性案例，已经存在。这个新的 API 只是接口的标准化，用于与它们进行交互：

• 正确性：declare_reachable在某些情况下可能会有所帮助，但在大多数情况下应该是自动的
• 性能：例如，此类 GC 不是类型感知的，可能会错误地检测包含整数的内存区域中的指针; declare_no_pointers消除了扫描某些内存区域的需要，从而提高了性能并减少了误报(这反过来又进一步提高了性能(

因此，如果您愿意，您已经可以使用 Boehm 的垃圾收集器，C++11 只是通过标准 API 对其进行了改进，以便您可以更轻松地从一个 GC 切换到另一个 GC。

包含垃圾回收的实现可能无法符合 C++98 或 C++03。C++11 增加了足够的内容以允许一致性，并且只是超越了这一步，试图使其稍微合理。

有人提议在标准中添加更全面的GC支持，但被拒绝。我认为拒绝是相当合理的。该提案对标准进行了大约40页的更改，但最终所有这些都是为了支持一个非规范性脚注，例如："预计高质量的实现将尝试最大化程序可用的内存。

就实现而言，曾经(在 egcs 时代(有人谈论将 Boehm-Demers-Weiser 收集器合并(修改版本(到 egcs 中。我似乎记得至少有一个版本在某种程度上这样做了(尽管我不记得它是否曾经被认为是"发布"版本(。然而，那是很久以前的事了，据我所知，多年来没有人做过这件事。与此同时，GCC已经发生了足够的变化，如果有人今天想这样做，他们可能不得不从头开始。

我想这至少摆脱了一个Microsoft的 C++/CLI 不符合标准的领域，因此根据您在其他地方想要多少一致性，您可以(有点(将 C++/CLI 视为垃圾回收C++。不过，大多数人认为它不太受欢迎(甚至Microsoft只推荐它用于链接 .NET 和实际C++之间的互操作(。

Clang以LLVM为目标，其中包括支持GC的钩子(已经在其他项目中使用和验证(。因此，它可能最有可能在相对较快的某个时间产生有效的实现。

虽然我显然可能是错的，但我不希望英特尔很快合并垃圾收集器。英特尔专注于生成最好的输出代码，而GC可能不会对此有很大帮助。他们可能这样做的主要原因是简化多线程，这是英特尔投入大量精力的另一个领域(但至少到目前为止，库比编译器本身更多(。

至于GC在大多数发布的C++代码中成为主流使用，似乎很少或根本没有需求甚至兴趣。当我最初写这个答案时，我猜现在有人会写一个。在那段时间里，C++对GC的兴趣似乎已经减弱，以至于我完全不相信它真的可能发生了。它仍然可能发生，但我没有看到足够的兴趣来预测它很有可能的时间框架。如果有的话，我猜可能会更有兴趣转向一个明确编纂一些 RAII 语义的类似 Rust 的模型(但尽管这个总体想法似乎引起了一些兴趣，但我还没有看到任何足够具体的东西来预测它何时可能发生(。

C++11 标准增加了对实现垃圾回收的语言支持，但没有实际工作的垃圾回收器。用于C++工作 gc 库的最突出的例子是 Hans Boehm 的实现。据我所知，目前还没有计划将此库与任何主要编译器集成，但已经多次暗示该标准的委员会非常有兴趣(*(将垃圾收集器与下一个版本的C++集成。

(*( 例如，参见 2012 年 Go Native 的专家小组