C++11 中的垃圾回收

Garbage Collection in C++11(C++11 中的垃圾回收)

问题描述

我一直在研究和使用 C++11 的不同功能，特别是在 Visual Studio 2010 中.

I have been looking through and playing with different features of C++11, specifically in Visual Studio 2010.

提到的一件事是最少的垃圾收集:

根据这篇博文，VC10支持这个功能.

According to this blog post, VC10 supports this feature.

我的测试表明，在丢失的对象上没有调用析构函数，因此我不确定它们的内存位置是否已被释放或是否正在泄漏.

My tests show that the destructor is not called on objects that are lost, so I am not sure as to whether their memory location has been freed or if they are leaking.

我无意以任何方式依赖它，但找不到关于其行为的直接、明确的答案.

I have no intention of depending on it, by any means, but couldn't find a straight, definitive answer on its behavior.

推荐答案

Minimal GC support (n2670) 只意味着像 std::declare_reachable 包含在内，并定义了安全派生指针"的含义，因此使某些操作(如 XOR-ing 指针值)成为未定义的行为，并且GC不需要担心.另请参阅 Bjarne Stroustrup 关于 GC ABI 的 C++11 常见问题解答，以及 n2585:对垃圾的最小支持基于收集和可达性的泄漏检测.

Minimal GC support (n2670) only means functions like std::declare_reachable are included, and define what is the meaning of a "safely-derived pointer", so making certain operations like XOR-ing pointer values becomes undefined behavior and the GC don't need to worry about it. See also Bjarne Stroustrup's C++11 FAQ on the GC ABI, and n2585: Minimal Support for Garbage Collection and Reachability-Based Leak Detection.

该提案允许在 C++11 的框架内实现 GC.但提案本身并不意味着实现需要支持 GC.一些图书馆，例如libc++ 只是将库函数实现为无操作.

The proposal allows a GC to be implemented within C++11's framework. But the proposal itself does not mean the implementation needs to support GC. Some library e.g. libc++ simply implement the library functions as no-op.

我很确定，此时，您的案例中的内存刚刚泄漏.但请注意，在 GC 发生时，确实不需要运行析构函数.假设§3.8 对象生命周期"也提供给 GC-ed 指针，我们有(§3.8/4):

I'm pretty sure, at this point, the memory in your case is just leaked away. But notice that the destructor is indeed not required to run when GC happens. Assuming "§3.8 Object lifetime" also supplies to GC-ed pointers, we have (§3.8/4):

...对于具有非平凡析构函数的类类型的对象，在对象占用的存储被重用或释放之前，程序不需要显式调用析构函数；但是，如果没有显式调用析构函数或者如果没有使用删除表达式 (5.3.5) 来释放存储，则不应隐式调用析构函数以及依赖于析构函数产生的副作用的任何程序有未定义的行为.

... For an object of a class type with a non-trivial destructor, the program is not required to call the destructor explicitly before the storage which the object occupies is reused or released; however, if there is no explicit call to the destructor or if a delete-expression (5.3.5) is not used to release the storage, the destructor shall not be implicitly called and any program that depends on the side effects produced by the destructor has undefined behavior.

所以也有可能在没有调用析构函数的情况下内存已经被释放.事实上，早期的 GC 提案如 n2310: Transparent Programmer-Directed Garbage Collection对于 C++ 明确指出 (n2310 §7)

So it is also possible the memory is already freed without the destructor called. In fact, earlier GC proposals such as n2310: Transparent Programmer-Directed Garbage Collection for C++ explicitly states that (n2310 §7)

当一个对象被垃圾回收器回收时，它的析构函数不会被调用(Of当然，显式删除总是调用析构函数).

When an object is recycled by the garbage collector, its destructor is not invoked (Of course, explicit deletion always invokes destructors).

这篇关于C++11 中的垃圾回收的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持编程学习网！