简短的回答: 我们不知道如何高效地(在很少的时间和空间开销下)并且始终(在所有可能的情况下)正确地进行垃圾收集。

长一点的回答: 就像C一样，c++是一种系统语言;这意味着当您编写系统代码时，例如操作系统时，将使用它。换句话说，c++就像C一样，以尽可能好的性能作为主要目标。该语言标准不会增加任何可能阻碍性能目标的特性。

这暂停了这个问题:为什么垃圾收集会影响性能?主要原因是，当涉及到实现时，我们(计算机科学家)不知道如何在所有情况下以最小的开销进行垃圾收集。因此，c++编译器和运行时系统不可能一直有效地执行垃圾收集。另一方面，c++程序员应该了解他的设计/实现，他是决定如何最好地进行垃圾收集的最佳人选。

最后，如果控制(硬件、细节等)和性能(时间、空间、电源等)不是主要的限制，那么c++就不是合适的工具。其他语言可能会更好，并提供更多[隐藏的]运行时管理，以及必要的开销。

虽然这是一个老问题，但仍然有一个问题我没有看到任何人解决过:垃圾收集几乎不可能指定。

特别是，c++标准非常谨慎地根据外部可观察到的行为来指定语言，而不是实现如何实现该行为。然而，在垃圾收集的情况下，实际上没有外部可观察到的行为。

The general idea of garbage collection is that it should make a reasonable attempt at assuring that a memory allocation will succeed. Unfortunately, it's essentially impossible to guarantee that any memory allocation will succeed, even if you do have a garbage collector in operation. This is true to some extent in any case, but particularly so in the case of C++, because it's (probably) not possible to use a copying collector (or anything similar) that moves objects in memory during a collection cycle.

如果不能移动对象，就不能创建一个单独的、连续的内存空间来进行分配——这意味着您的堆(或自由存储区，或任何您喜欢称呼它的地方)可能会随着时间的推移而变得碎片化。这反过来又会阻止分配成功，即使空闲内存比请求的内存多。

尽管有可能提出某种保证，即(本质上)如果您重复完全相同的分配模式，并且它在第一次成功，那么它将在后续迭代中继续成功，前提是分配的内存在迭代之间变得不可访问。这是一个非常微弱的保证，基本上毫无用处，但我看不到任何加强它的合理希望。

即便如此，它也比为c++所提议的更强大。之前的提议[警告:PDF](被放弃了)根本不能保证任何东西。在28页的提案中，你在外部可观察到的行为中看到的是一个单一的(不规范的)注释:

[注意:对于垃圾收集程序，高质量的托管实现应该尝试最大限度地回收不可访问的内存量。-结束注释]

至少对我来说，这引发了一个关于投资回报的严肃问题。我们将破坏现有的代码(没有人知道具体破坏了多少，但肯定是相当多)，对实现提出新的要求，对代码提出新的限制，而我们得到的回报很可能是什么都没有?

即使在最好的情况下，我们得到的是基于Java测试的程序，以现在相同的速度运行可能需要大约6倍的内存。更糟糕的是，垃圾收集从一开始就是Java的一部分——c++对垃圾收集器施加了足够多的限制，以至于它几乎肯定会有更糟糕的成本/收益比(即使我们超出了提案所保证的范围，并假设会有一些收益)。

我要用数学方法总结一下情况:这是一个复杂的情况。数学家都知道，复数有两部分:实数和虚数。在我看来，我们这里的成本是真实的，但收益(至少大部分)是虚构的。

什么类型?它应该针对嵌入式洗衣机控制器、手机、工作站或超级计算机进行优化吗? 它应该优先考虑gui响应还是服务器加载? 它应该使用大量内存还是大量CPU?

C/c++被用于太多不同的环境。 我怀疑像增强智能指针这样的东西对大多数用户来说就足够了

编辑:自动垃圾收集器并不是一个性能问题(你总是可以购买更多的服务器)，而是一个可预测的性能问题。 不知道GC什么时候会起作用就像雇佣一个嗜睡症的飞行员，大多数时候他们是很棒的-但当你真的需要响应的时候!

强制垃圾收集实际上是一个低级到高级的范式转换。

If you look at the way strings are handled in a language with garbage collection, you will find they ONLY allow high level string manipulation functions and do not allow binary access to the strings. Simply put, all string functions first check the pointers to see where the string is, even if you are only drawing out a byte. So if you are doing a loop that processes each byte in a string in a language with garbage collection, it must compute the base location plus offset for each iteration, because it cannot know when the string has moved. Then you have to think about heaps, stacks, threads, etc etc.

当我们比较c++和Java时，我们看到c++在设计时并没有考虑到隐式垃圾收集，而Java则是。

在C风格中使用任意指针这样的东西不仅不利于gc实现，而且还会破坏大量c++遗留代码的向后兼容性。

除此之外，c++是一种旨在作为独立可执行文件运行的语言，而不是具有复杂的运行时环境。

总之: 是的，在c++中添加垃圾收集是可能的，但是为了连续性，最好不要这样做。

c++背后的思想是，你不需要为你不使用的特性付出任何性能上的影响。因此，添加垃圾收集意味着让一些程序像C语言那样直接在硬件上运行，而另一些则在某种运行时虚拟机中运行。

没有什么可以阻止您使用绑定到某些第三方垃圾收集机制的某种形式的智能指针。我似乎记得微软在COM上做过类似的事情，但并不顺利。