C++ 中的垃圾收集――为什么?
我不断听到有人抱怨 C++ 没有垃圾收集.我还听说 C++ 标准委员会正在考虑将其添加到该语言中.恐怕我只是不明白它的意义......使用带有智能指针的 RAII 消除了对它的需要，对吧?
I keep hearing people complaining that C++ doesn't have garbage collection. I also hear that the C++ Standards Committee is looking at adding it to the language. I'm afraid I just don't see the point to it... using RAII with smart pointers eliminates the need for it, right?
我唯一的垃圾收集经验是在几台便宜的 80 年代家用电脑上，这意味着系统每隔一段时间就会死机几秒钟.我确信从那以后它已经有所改善，但正如你猜到的那样，这并没有让我对它有很高的评价.
My only experience with garbage collection was on a couple of cheap eighties home computers, where it meant that the system would freeze up for a few seconds every so often. I'm sure it has improved since then, but as you can guess, that didn't leave me with a high opinion of it.
垃圾回收可为有经验的 C++ 开发人员提供哪些优势?
What advantages could garbage collection offer an experienced C++ developer?
推荐答案
我经常听到有人抱怨 C++ 没有垃圾收集功能.
我为他们感到难过.认真的.
I keep hearing people complaining that C++ doesn't have garbage collection.
I am so sorry for them. Seriously.
C++ 有 RAII，我总是抱怨在垃圾收集语言中找不到 RAII(或阉割的 RAII).
C++ has RAII, and I always complain to find no RAII (or a castrated RAII) in Garbage Collected languages.
另一个工具.
Matt J 在他的帖子(C++ 中的垃圾收集――为什么?):我们不需要 C++ 功能，因为它们中的大多数都可以用 C 编码，我们也不需要 C 功能，因为它们中的大多数可以用汇编编码，等等.C++ 必须发展.
Matt J wrote it quite right in his post (Garbage Collection in C++ -- why?): We don't need C++ features as most of them could be coded in C, and we don't need C features as most of them could coded in Assembly, etc.. C++ must evolve.
作为开发人员:我不关心 GC.我尝试了 RAII 和 GC，我发现 RAII 非常优越.正如 Greg Rogers 在他的帖子中所说(C++ 中的垃圾收集――为什么?)，内存泄漏并没有那么可怕(至少在 C++ 中，如果真正使用 C++，它们很少见)以证明 GC 而不是 RAII.GC 具有非确定性的释放/终结，只是一种编写不关心特定内存选择的代码的方法.
As a developer: I don't care about GC. I tried both RAII and GC, and I find RAII vastly superior. As said by Greg Rogers in his post (Garbage Collection in C++ -- why?), memory leaks are not so terrible (at least in C++, where they are rare if C++ is really used) as to justify GC instead of RAII. GC has non deterministic deallocation/finalization and is just a way to write a code that just don't care with specific memory choices.
最后一句话很重要:编写不关心"的代码很重要.就像在 C++ RAII 中一样，我们不关心资源释放，因为 RAII 为我们做，或者对象初始化，因为构造函数为我们做，有时只写代码而不关心谁是什么内存的所有者，这很重要，以及我们需要什么样的指针(共享的、弱的等)来处理这段或这段代码.在 C++ 中似乎需要 GC.(即使我个人没看到)
This last sentence is important: It is important to write code that "juste don't care". In the same way in C++ RAII we don't care about ressource freeing because RAII do it for us, or for object initialization because constructor do it for us, it is sometimes important to just code without caring about who is owner of what memory, and what kind pointer (shared, weak, etc.) we need for this or this piece of code. There seems to be a need for GC in C++. (even if I personaly fail to see it)
有时，在应用程序中，您有浮动数据".想象一下数据的树状结构，但没有人是真正的所有者".数据(并且没有人真正关心它何时会被销毁).多个对象可以使用它，然后丢弃它.当没有人再使用它时，您希望它被释放.
Sometimes, in an app, you have "floating data". Imagine a tree-like structure of data, but no one is really "owner" of the data (and no one really cares about when exactly it will be destroyed). Multiple objects can use it, and then, discard it. You want it to be freed when no one is using it anymore.
C++ 方法使用智能指针.boost::shared_ptr 浮现在脑海中.因此，每条数据都由其自己的共享指针拥有.凉爽的.问题是当每条数据都可以引用另一条数据时.您不能使用共享指针，因为它们使用的是引用计数器，它不支持循环引用(A 指向 B，B 指向 A).所以你必须知道在哪里使用弱指针(boost::weak_ptr)，以及何时使用共享指针.
The C++ approach is using a smart pointer. The boost::shared_ptr comes to mind. So each piece of data is owned by its own shared pointer. Cool. The problem is that when each piece of data can refer to another piece of data. You cannot use shared pointers because they are using a reference counter, which won't support circular references (A points to B, and B points to A). So you must know think a lot about where to use weak pointers (boost::weak_ptr), and when to use shared pointers.
使用 GC，您只需使用树结构数据.
With a GC, you just use the tree structured data.
缺点是您不必关心何时浮动数据".真的会被摧毁.只是它会被销毁.
The downside being that you must not care when the "floating data" will really be destroyed. Only that it will be destroyed.
所以最后，如果处理得当，并且与当前的 C++ 习语兼容，GC 将是另一个 C++ 的好工具.
So in the end, if done properly, and compatible with the current idioms of C++, GC would be a Yet Another Good Tool for C++.
C++ 是一种多范式语言:添加 GC 可能会让一些 C++ 粉丝因为叛国而哭泣，但最终，这可能是个好主意，我猜 C++ 标准委员会不会让这种专业特性破坏了语言，所以我们可以相信他们会进行必要的工作，以启用不会干扰 C++ 的正确 C++ GC:与 C++ 一样，如果您不需要某个特性，请不要使用它不会花你任何钱.
C++ is a multiparadigm language: Adding a GC will perhaps make some C++ fanboys cry because of treason, but in the end, it could be a good idea, and I guess the C++ Standards Comitee won't let this kind of major feature break the language, so we can trust them to make the necessary work to enable a correct C++ GC that won't interfere with C++: As always in C++, if you don't need a feature, don't use it and it will cost you nothing.
相关文章