我一直在尝试更深入地研究指针的局限性,以了解它们如何在幕后影响程序。我的研究导致我提出的一件事是,指示器创建的变量必须用C ++等语言删除,否则数据仍将在内存上。
我的问题涉及在功能生命周期结束后访问数据。如果我在函数中创建一个指针变量,然后该函数即可到达适当的关闭,那么如何访问数据?实际上,这只是垃圾占用空间吗?还是应该有一种在不存储地址在另一个变量中的情况下仍然引用它的方法?
I have been trying to dive deeper into the limitations of pointers to see how they effect the program behind the scenes. One thing my research has led me to is the variables created by pointers must be deleted in a language like C++, otherwise the data will still be on memory.
My question pertains to accessing the data after a functions lifecycle ends. If I create a pointer variable within a function, and then the function comes to a proper close, how would the data be accessed? Would it actually be just garbage taking up space, or is there supposed to be a way to still reference it without having stored the address in another variable?
发布评论
评论(2)
没有自动垃圾收集。如果您将句柄(指针,参考,索引,...)丢给了您的资源,您的资源将实时 ad vitamæternam。
如果您希望自己的资源在将其手柄范围范围内停止时停止生活,那么RAII和智能指针就是您所需的工具。
如果您希望自己的资源在其手柄不在范围之后继续寿命,则需要复制手柄并将其传递。
There's no automatic garbage collection. If you lose the handle (pointer, reference, index, ...) to your resource, your resource will live ad vitam æternam.
If you want your resources to cease to live when their handle goes out of scope, RAII and smart pointers are the tool you need.
If you want your resources to continue to live after their handle goes out of scope, you need to copy the handle and pass it around.
使用标准智能指针 std :: simelor_ptr 和和 std :: sharde_ptr 当指针脱离范围时,释放了内存。范围末端后对象立即被销毁+释放,并且无法再访问它。除非您将指针从范围中移出到更大的范围,否则它将被删除。
但是,实施懒惰的垃圾收集器并不难。与您在各处使用智能指针一样,但Lazey变体也一样。现在,当指针脱离范围时,其对象不会立即被销毁+释放,而是将其委派给了懒惰的垃圾收集器,后者将在稍后在单独的线程中销毁+将其释放。正是我在下面的代码中实现的这种懒惰行为。
我仅出于娱乐而实现了以下代码,作为您的演示,没有重要的一点,为什么不使用
std :: simelor_ptr
和std :: shared_ptr的标准贪婪释放技术/代码>。尽管有一个非常重要的用例-STD :: shared_ptr构造代码中的对象,当您调用构造函数时,并且您知道构造时间,但是在代码和时间的不同未定义点上摧毁了对象,因为有共享共享指针的副本。因此,您可能会在未预测的时间点上长期破坏延误,这可能会损害实时高性能代码。另外,破坏时间可能太大了。懒惰的删除将破坏移动到单独的线程中,可以以自己的节奏删除它。
尽管智能指针在范围内懒惰地处置,但是在一些纳米秒(甚至是微型秒)中,您可能仍然可以访问其未播放的/未经遗产的内存,但不能保证时间。这只是意味着真正的破坏可能比范围末端晚得多,因此是懒惰垃圾收集器的名称。您甚至可以调整这种懒惰的垃圾收集器,以便它确实删除了对象,请说1毫米之后,它们的智能指针被摧毁了。
真正的垃圾收集器正在做类似的事情,它们会在更晚的时间内释放对象,并且通常通过在内存中找到看起来像真正的堆指针的字节来自动这样做。
我的代码中有一个
test()
函数,该功能显示了我如何使用标准指针的懒惰变体。同样,当代码运行时,您可能会在控制台输出中看到它显示的内容类似:在括号中,它显示了对象的ID(其指针的较低位)。您可能会看到处置和破坏是按照建筑顺序完全相反的顺序进行的。在测试完成之前,将懒垃圾收集器处置为懒惰垃圾收集器。虽然实际破坏在测试完成后稍后在单独的线程中发生。
在线尝试!
Using standard smart pointers std::unique_ptr and std::shared_ptr memory is freed when pointer goes out of scope. After scope ends object is immediately destroyed+freed and there is no way to access it anymore. Unless you move/copy pointer out of scope to bigger scope, where it will be deleted.
But there is not so difficult to implement lazy garbage collector. Same as before you use smart pointers everywhere, but lazey variant. Now when pointer goes out of scope its object is not immediately destroyed+freed, but instead is delegated to lazy garbage collector, which will destroy+free it later in a separate thread. Exactly this lazy behaviour I implemented in my code below.
I implemented following code from scratch just for fun and as a demo for you, there is no big point why not to use standard greedy freeing techniques of
std::unique_ptr
andstd::shared_ptr
. Although there is one very important use case - std::shared_ptr constructs objects at well known points in code, when you call constructor, and you know construction time well, but destroys objects at different undefined points in code and time, because there are shared copies of shared pointer. Thus you may have long destruction delays at unpredicted points in time, which may harm realtime high performance code. Also destruction time might be too big. Lazy deleting moves destruction into separate thread where it can be deleted at its own pace.Although smart pointer is lazily disposed at scope end, but yet for some nano seconds (or even micro seconds) you may still have access to its undestroyed/unfreed memory, of course time is not guaranteed. This just means that real destruction can happen much later than scope ends, thus is the name of lazy garbage collector. You can even tweak this kind of lazy garbage collector so that it really deletes objects lets say after 1 milli second after theirs smart pointers have been destroyed.
Real garbage collectors are doing similar thing, they free objects much later in time and usually do it automatically by finding bytes in memory that look like real pointers of heap.
There is a
Test()
function in my code that shows how my lazy variants of standard pointers are used. Also when code is runned you may see in console output that it shows something like:Here in parenthesis it shows id of object (lower bits of its pointer). You may see that disposal and destruction is done in order exactly opposite to construction order. Disposal to lazy garbage collector happens before test finishes. While real destruction happens later in a separate thread after test finishes.
Try it online!