我问这个问题，首先不是因为垃圾收集的优点。我问这个问题的主要原因是我知道Bjarne Stroustrup说过c++在某个时间点上会有一个垃圾收集器。
话虽如此，为什么还没有加入呢?c++已经有了一些垃圾收集器。这是那种“说起来容易做起来难”的事情吗?或者还有其他原因没有添加它(并且不会在c++ 11中添加)?
交叉链接:
c++的垃圾收集器
澄清一下，我理解c++最初创建时没有垃圾收集器的原因。我想知道为什么不能添加收集器。
当前回答
要回答关于c++的大多数“为什么”问题，请阅读c++的设计与进化
其他回答
c++背后的思想是，你不需要为你不使用的特性付出任何性能上的影响。因此，添加垃圾收集意味着让一些程序像C语言那样直接在硬件上运行，而另一些则在某种运行时虚拟机中运行。
没有什么可以阻止您使用绑定到某些第三方垃圾收集机制的某种形式的智能指针。我似乎记得微软在COM上做过类似的事情，但并不顺利。
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)向后兼容。
希望这能有所帮助。
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++和Java时，我们看到c++在设计时并没有考虑到隐式垃圾收集，而Java则是。
在C风格中使用任意指针这样的东西不仅不利于gc实现，而且还会破坏大量c++遗留代码的向后兼容性。
除此之外，c++是一种旨在作为独立可执行文件运行的语言，而不是具有复杂的运行时环境。
总之: 是的，在c++中添加垃圾收集是可能的，但是为了连续性，最好不要这样做。
要回答关于c++的大多数“为什么”问题，请阅读c++的设计与进化
