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

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?

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

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

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.

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。

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

为了增加争论。

关于垃圾收集有一些已知的问题，了解它们有助于理解为什么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…然而，这不是一个微不足道的问题。与此同时，我们只需要卷起袖子。