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

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

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

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

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

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

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

c++没有内置垃圾回收的最大原因之一是，让垃圾回收很好地使用析构函数是非常非常困难的。据我所知，还没有人真正知道如何完全解决这个问题。有很多问题需要处理:

deterministic lifetimes of objects (reference counting gives you this, but GC doesn't. Although it may not be that big of a deal). what happens if a destructor throws when the object is being garbage collected? Most languages ignore this exception, since theres really no catch block to be able to transport it to, but this is probably not an acceptable solution for C++. How to enable/disable it? Naturally it'd probably be a compile time decision but code that is written for GC vs code that is written for NOT GC is going to be very different and probably incompatible. How do you reconcile this?

这些只是面临的问题中的一小部分。

原始C语言背后的一个基本原则是，内存是由一系列字节组成的，代码只需要关心这些字节在被使用的确切时刻意味着什么。现代C语言允许编译器施加额外的限制，但C语言包括——c++保留了——将指针分解为字节序列，将包含相同值的任何字节序列组装为指针，然后使用该指针访问先前的对象。

While that ability can be useful--or even indispensable--in some kinds of applications, a language that includes that ability will be very limited in its ability to support any kind of useful and reliable garbage collection. If a compiler doesn't know everything that has been done with the bits that made up a pointer, it will have no way of knowing whether information sufficient to reconstruct the pointer might exist somewhere in the universe. Since it would be possible for that information to be stored in ways that the computer wouldn't be able to access even if it knew about them (e.g. the bytes making up the pointer might have been shown on the screen long enough for someone to write them down on a piece of paper), it may be literally impossible for a computer to know whether a pointer could possibly be used in the future.

An interesting quirk of many garbage-collected frameworks is that an object reference not defined by the bit patterns contained therein, but by the relationship between the bits held in the object reference and other information held elsewhere. In C and C++, if the bit pattern stored in a pointer identifies an object, that bit pattern will identify that object until the object is explicitly destroyed. In a typical GC system, an object may be represented by a bit pattern 0x1234ABCD at one moment in time, but the next GC cycle might replace all references to 0x1234ABCD with references to 0x4321BABE, whereupon the object would be represented by the latter pattern. Even if one were to display the bit pattern associated with an object reference and then later read it back from the keyboard, there would be no expectation that the same bit pattern would be usable to identify the same object (or any object).

主要有两个原因:

因为它不需要(恕我直言) 因为它与RAII几乎不兼容，RAII是c++的基石

c++已经提供了手动内存管理、堆栈分配、RAII、容器、自动指针、智能指针……这应该足够了。垃圾收集器适合懒惰的程序员，他们不想花5分钟思考谁应该拥有哪些对象或什么时候应该释放资源。这不是我们在c++中做事情的方式。

本来可以添加隐式垃圾收集，但它没有达到要求。可能不仅仅是因为实现的复杂性，还因为人们不能足够快地达成普遍共识。

引用Bjarne Stroustrup自己的话:

我本来希望是个收垃圾的 哪些可以选择启用 是c++ 0x的一部分，但是 我有足够多的技术问题 凑合着用一个详细的 如何规范这样的收集器 的其余部分集成 语言，如果提供的话。事实就是这样 基本上拥有c++ 0x的所有特性， 存在一个实验性的实现。

这里有关于这个话题的很好的讨论。

总体概述:

c++非常强大，几乎可以做任何事情。由于这个原因，它不会自动将许多可能影响性能的东西推给您。垃圾收集可以很容易地用智能指针(用引用计数包装指针的对象，当引用计数达到0时自动删除自己)实现。

c++在构建时考虑到了没有垃圾收集功能的竞争对手。与C和其他语言相比，效率是c++必须抵御批评的主要问题。

垃圾收集有两种类型…

显式垃圾收集:

c++ 0x通过shared_ptr创建的指针进行垃圾收集

如果你想要它，你可以使用它，如果你不想要它，你不会被迫使用它。

对于c++ 0x之前的版本，boost:shared_ptr是存在的，用途相同。

隐式垃圾收集:

但是它没有透明的垃圾收集。不过，它将是未来c++规范的一个焦点。

为什么Tr1没有隐式垃圾收集?

c++ 0x的tr1应该有很多东西，Bjarne Stroustrup在之前的采访中说tr1没有他想要的那么多。