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比许多其他语言更短，更容易阅读，也更容易教授。

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)向后兼容。

希望这能有所帮助。

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

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

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

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

要回答关于c++的大多数“为什么”问题，请阅读c++的设计与进化

为了增加争论。

关于垃圾收集有一些已知的问题，了解它们有助于理解为什么c++中没有垃圾收集。

1. 性能?

第一个抱怨通常是关于性能，但大多数人并没有真正意识到他们在谈论什么。正如马丁·贝克特(Martin Beckett)所指出的，问题可能不是表现本身，而是表现的可预测性。

目前有两个GC家族被广泛部署:

标记和清扫类 引用计数类型

标记和清除更快(对整体性能的影响较小)，但它患有“冻结世界”综合征:即当GC开始时，其他一切都停止，直到GC完成清理。如果您希望构建一个在几毫秒内响应的服务器……有些交易不会达到你的期望:)

The problem of Reference Counting is different: reference-counting adds overhead, especially in Multi-Threading environments because you need to have an atomic count. Furthermore there is the problem of reference cycles so you need a clever algorithm to detect those cycles and eliminate them (generally implement by a "freeze the world" too, though less frequent). In general, as of today, this kind (even though normally more responsive or rather, freezing less often) is slower than the Mark And Sweep.

I have seen a paper by Eiffel implementers that were trying to implement a Reference Counting Garbage Collector that would have a similar global performance to Mark And Sweep without the "Freeze The World" aspect. It required a separate thread for the GC (typical). The algorithm was a bit frightening (at the end) but the paper made a good job of introducing the concepts one at a time and showing the evolution of the algorithm from the "simple" version to the full-fledged one. Recommended reading if only I could put my hands back on the PDF file...

2. 资源获取初始化(RAII)

在c++中，将资源的所有权包装在对象中以确保它们被正确地释放是一种常见的习惯用法。它主要用于内存，因为我们没有垃圾回收，但它对许多其他情况也很有用:

锁(多线程，文件句柄，…) 连接(到数据库、另一台服务器……)

其思想是正确地控制对象的生命周期:

只要你需要，它就应该是活的 当你用完它的时候，它应该被杀死

GC的问题在于，如果它有助于前者，并最终保证以后……这个“终极”可能还不够。如果你释放一个锁，你真的希望它现在被释放，这样它就不会阻止任何进一步的调用!

带有GC的语言有两种解决方法:

当堆栈分配足够时不要使用GC:这通常是为了解决性能问题，但在我们的例子中，它确实有帮助，因为作用域定义了生命周期 使用构造…但它是显式(弱)RAII，而在c++中RAII是隐式的，因此用户不能在不知不觉中犯错误(通过省略using关键字)

3.智能指针

在c++中，智能指针通常是处理内存的灵丹妙药。我经常听到:我们根本不需要GC，因为我们有智能指针。

这是大错特错了。

智能指针确实有帮助:auto_ptr和unique_ptr使用RAII概念，确实非常有用。它们很简单，你可以很容易地自己写出来。

然而，当一个人需要共享所有权时，它变得更加困难:你可能在多个线程之间共享，并且在计数的处理上有一些微妙的问题。因此，很自然地使用shared_ptr。

这很棒，毕竟这就是Boost的用途，但它并不是万能的。事实上，shared_ptr的主要问题是它模拟了一个由引用计数实现的GC，但你需要自己实现周期检测…开始

当然有这个weak_ptr的东西，但不幸的是，我已经看到内存泄漏尽管使用shared_ptr，因为这些周期…当你在多线程环境中，它是非常难以检测的!

4. 解决方案是什么?

没有什么灵丹妙药，但一如既往，这绝对是可行的。在没有GC的情况下，需要明确所有权:

如果可能的话，最好在一个特定的时间拥有一个所有者 如果没有，请确保您的类图没有与所有权相关的任何循环，并通过weak_ptr的微妙应用来打破它们

所以，如果有一个GC…然而，这不是一个微不足道的问题。与此同时，我们只需要卷起袖子。

主要有两个原因:

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

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