垃圾收集在C ++ 11 [英] Garbage Collection in C++11

查看:161
本文介绍了垃圾收集在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.

推荐答案

最小GC支持(n2670)只是指函数 std :: declare_reachable ,并定义什么是安全派生的指针,所以使某些操作像XOR指针值变成未定义的行为,GC不需要担心它。另请参见 GC ABI上的Bjarne Stroustrup的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.8Object lifetime也提供给GC编译的指针,我们有(§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):


...具有非平凡析构函数的类类型的对象,程序不需要在对象占用的存储之前显式地调用析构函数被重用或释放;然而,如果没有对析构函数的显式调用,或者如果没有使用delete-expression(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:透明程序员指导的垃圾收集对于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)


当一个对象被垃圾回收器回收时,它的析构函数不是调用(
课程,显式删除总是调用析构函数)。

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

这篇关于垃圾收集在C ++ 11的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆