主要有两个原因:

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

c++已经提供了手动内存管理、堆栈分配、RAII、容器、自动指针、智能指针……这应该足够了。垃圾收集器适合懒惰的程序员，他们不想花5分钟思考谁应该拥有哪些对象或什么时候应该释放资源。这不是我们在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…然而，这不是一个微不足道的问题。与此同时，我们只需要卷起袖子。

tl;dr:因为现代c++不需要垃圾收集。

Bjarne Stroustrup对此问题的常见问题解答如下:

我不喜欢垃圾。我不喜欢乱扔垃圾。我的理想是通过不产生任何垃圾来消除对垃圾收集器的需求。现在这是可能的。

---

现在编写的代码(c++ 17和遵循官方核心指南)的情况如下:

Most memory ownership-related code is in libraries (especially those providing containers). Most use of code involving memory ownership follows the CADRe or RAII pattern, so allocation is made on construction and deallocation on destruction, which happens when exiting the scope in which something was allocated. You do not explicitly allocate or deallocate memory directly. Raw pointers do not own memory (if you've followed the guidelines), so you can't leak by passing them around. If you're wondering how you're going to pass the starting addresses of sequences of values in memory - you can and should prefer span's, obviating the need for raw pointers. You can still use such pointers, they'll just be non-owning. If you really need an owning "pointer", you use C++' standard-library smart pointers - they can't leak, and are decently efficient (although the ABI can get in the way of that). Alternatively, you can pass ownership across scope boundaries with "owner pointers". These are uncommon and must be used explicitly; but when adopted - they allow for nice static checking against leaks.

“哦,是吗?但是……

．.． 如果我只是像以前写c++那样写代码?”

实际上，您可以忽略所有的指导方针，编写有漏洞的应用程序代码——它将像往常一样编译和运行(并泄漏)。

但这并不是一种“不要这么做”的情况，即开发者应该保持良好的自我控制;编写不符合规范的代码并不简单，也没有更快，也没有更好的性能。慢慢地，它也会变得更加难以编写，因为你将面临与符合规范的代码所提供和期望的“阻抗不匹配”的增加。

．.． 如果我retrepret_cast ?或者做复杂的指针运算?还是其他类似的黑客?”

事实上，如果你用心去做，你可以编写一些代码，尽管你很好地遵循了指导原则。但是:

您很少会这样做(就代码中的位置而言，而不一定是就执行时间的比例而言) 你只会故意这么做，而不是意外。 这样做将在符合准则的代码库中脱颖而出。 在这种代码中，您无论如何都可以在另一种语言中绕过GC。

．.． 图书馆发展?”

如果你是c++库开发人员，那么你确实会编写包含原始指针的不安全代码，并且你被要求谨慎而负责地编码——但这些是由专家编写的自包含代码片段(更重要的是，由专家评审)。

所以，就像Bjarne说的:一般来说，没有动机去收集垃圾，因为你只是确保不产生垃圾。GC正在成为c++的一个不成问题的问题。

这并不是说，当您希望使用自定义分配和反分配策略时，GC对于某些特定的应用程序不是一个有趣的问题。对于那些您想要自定义分配和反分配的对象，而不是语言级GC。

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

希望这能有所帮助。

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

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

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