主要有两个原因:

因为它不需要(恕我直言) 因为它与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没有他想要的那么多。

原始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).

If you want automatic garbage collection, there are good commercial and public-domain garbage collectors for C++. For applications where garbage collection is suitable, C++ is an excellent garbage collected language with a performance that compares favorably with other garbage collected languages. See The C++ Programming Language (4rd Edition) for a discussion of automatic garbage collection in C++. See also, Hans-J. Boehm's site for C and C++ garbage collection (archive). Also, C++ supports programming techniques that allow memory management to be safe and implicit without a garbage collector. I consider garbage collection a last choice and an imperfect way of handling for resource management. That does not mean that it is never useful, just that there are better approaches in many situations.

来源:http://www.stroustrup.com/bs_faq.html垃圾收集

至于为什么它没有内置它，如果我没记错的话，它是在GC出现之前发明的，我不相信这种语言有GC，有几个原因(我不相信它有GC)。C)向后兼容。

希望这能有所帮助。

Stroustrup在2013年的Going Native大会上对此发表了一些很好的评论。

在这个视频中跳过大约25m50s。(其实我建议你看完整个视频，但这段视频跳过了垃圾收集的内容。)

当您拥有一种非常优秀的语言，能够以直接的方式轻松(安全、可预测、易于阅读和易于教授)处理对象和值，避免(显式)使用堆时，您甚至不需要垃圾收集。

在现代c++和c++ 11中，垃圾收集不再需要，除非在有限的情况下。事实上，即使一个好的垃圾收集器内置于一个主要的c++编译器中，我认为它也不会经常使用。避免GC会更容易，而不是更难。

他举了一个例子:

void f(int n, int x) {
    Gadget *p = new Gadget{n};
    if(x<100) throw SomeException{};
    if(x<200) return;
    delete p;
}

This is unsafe in C++. But it's also unsafe in Java! In C++, if the function returns early, the delete will never be called. But if you had full garbage collection, such as in Java, you merely get a suggestion that the object will be destructed "at some point in the future" (Update: it's even worse that this. Java does not promise to call the finalizer ever - it maybe never be called). This isn't good enough if Gadget holds an open file handle, or a connection to a database, or data which you have buffered for write to a database at a later point. We want the Gadget to be destroyed as soon as it's finished, in order to free these resources as soon as possible. You don't want your database server struggling with thousands of database connections that are no longer needed - it doesn't know that your program is finished working.

那么解决方案是什么呢?有几种方法。最明显的方法，你将用于绝大多数的对象是:

void f(int n, int x) {
    Gadget p = {n};  // Just leave it on the stack (where it belongs!)
    if(x<100) throw SomeException{};
    if(x<200) return;
}

这需要更少的字符来输入。它没有新的障碍。它不需要您键入Gadget两次。对象在函数结束时被销毁。如果这是你想要的，这是非常直观的。gadget的行为与int或double相同。可预测，易读，易教。一切都是“价值”。有时是一个很大的值，但是值更容易教，因为你不需要指针(或引用)那样的“远距离操作”。

您创建的大多数对象仅用于创建它们的函数，并且可能作为输入传递给子函数。程序员不应该在返回对象时考虑“内存管理”，或者在软件的广泛分离部分之间共享对象。

范围和生命周期很重要。大多数情况下，如果生命期与作用域相同，就会更容易。这样更容易理解，也更容易教。当您想要不同的生存期时，阅读代码就会很明显地知道您正在这样做，例如通过使用shared_ptr。(或利用move-semantics或unique_ptr按值返回(大)对象。

这似乎是一个效率问题。如果我想从foo()返回一个Gadget怎么办?c++ 11的move语义使得返回大对象更容易。只需编写Gadget foo(){…它会起作用的，而且很快就会起作用。你不需要打扰&&自己，只需要按值返回，语言通常能够做必要的优化。(即使在c++ 03之前，编译器在避免不必要的复制方面做得非常好。)

正如Stroustrup在视频的其他地方所说的那样:“只有计算机科学家会坚持复制一个物体，然后破坏原始物体。(观众笑)。为什么不直接将对象移动到新位置呢?这是人类(而不是计算机科学家)所期望的。”

当您可以保证只需要一个对象的副本时，就更容易理解对象的生命周期。您可以选择您想要的生命周期策略，如果您愿意，垃圾收集就在那里。但是，当您了解其他方法的好处时，您会发现垃圾收集在首选列表的底部。

如果这对您不起作用，您可以使用unique_ptr，如果失败，可以使用shared_ptr。在内存管理方面，编写良好的c++ 11比许多其他语言更短，更容易阅读，也更容易教授。

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

特别是，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++对垃圾收集器施加了足够多的限制，以至于它几乎肯定会有更糟糕的成本/收益比(即使我们超出了提案所保证的范围，并假设会有一些收益)。

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