我问这个问题,首先不是因为垃圾收集的优点。我问这个问题的主要原因是我知道Bjarne Stroustrup说过c++在某个时间点上会有一个垃圾收集器。

话虽如此,为什么还没有加入呢?c++已经有了一些垃圾收集器。这是那种“说起来容易做起来难”的事情吗?或者还有其他原因没有添加它(并且不会在c++ 11中添加)?

交叉链接:

c++的垃圾收集器

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

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

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

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一样,c++是一种系统语言;这意味着当您编写系统代码时,例如操作系统时,将使用它。换句话说,c++就像C一样,以尽可能好的性能作为主要目标。该语言标准不会增加任何可能阻碍性能目标的特性。

这暂停了这个问题:为什么垃圾收集会影响性能?主要原因是,当涉及到实现时,我们(计算机科学家)不知道如何在所有情况下以最小的开销进行垃圾收集。因此,c++编译器和运行时系统不可能一直有效地执行垃圾收集。另一方面,c++程序员应该了解他的设计/实现,他是决定如何最好地进行垃圾收集的最佳人选。

最后,如果控制(硬件、细节等)和性能(时间、空间、电源等)不是主要的限制,那么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.