注册
登录
硬件Safety
内存领域的异常安全
返回
内存领域的异常安全
作者:
春风助手
发布时间:
2025-03-04 01:01:54 (2天前)
<p>我正在编写一个简单的内存竞技场分配器，并遇到一个异常安全的小问题。情况是当您分配一个本身称为分配器的对象时。内存池的目标是一次分配一堆对象，然后在销毁该池时将其全部删除。</p> <pre><code>{ MemoryArena m; std::string* ptr = m.Allocate<std::string>(); // use ptr whatever // Cleaned up when pool is destroyed } </code></pre><p>但是，当它多次使用时，会变得很讨厌。如果清理了内部分配，则可以在以后使用它-一个不错的假设，因为这是在生命周期结束之前从不删除对象的池的定义。考虑：</p> <pre><code>struct X { X(MemoryArena* ptr, std::string*& ref) { ref = ptr->Allocate<std::string>(); throw std::runtime_error("hai"); } }; MemoryArena m; std::string* ptr; m.Allocate<X>(&m, ptr); // ptr is invalid- even though it came from the arena // which hasn't yet been destroyed </code></pre><p>但是如果内部分配没有被清理，外部分配也不能被清理，因为内存领域像在硬件堆栈上那样线性地分配它们，所以我泄漏了内存。因此，要么我过早破坏对象就违反了我的语义，要么我泄漏了内存。</p><p>有关如何解决此问题的任何建议？</p>
收藏
举报
2 条回复
1#
回复此人
只怕再见是故人
|
2020-08-05 15-11
也许这只是适用于此的示例代码，但是我认为用户ptr在Xthrow 的构造函数中不应该认为该代码有效。也可能在分配ref之前就抛出了。 因此，我想说，如果可以的话，请清理内部对象（即，如果竞技场的前面当前位于内部对象的末端）。好了，来自竞技场的分配变得无效，这是不正常的，但是无论如何这是一个永远不应该进入现实世界的分配。 也许您可以使用“软”分配的概念来使之明确。它不能保证永远存在，因为尽管它仍然是“软”的，但可以释放回竞技场。然后，X的构造函数将执行以下操作： ``` SoftPtr<std::string> tmp(ptr->SoftAllocate<std::string>()); stuff_that_might_throw(); ref = tmp.release(); ``` SoftPtr不先调用就执行的析构函数release意味着没有公开对该对象的引用。它调用MemoryArena函数，其功能类似于： 破坏对象 检查这是否是来自竞技场的最新分配 如果是这样，请从竞技场的当前位置指针中减去大小 如果没有，则什么也不做（内存泄漏） 因此，只要逆序完成，就可以“撤回”任意数量的分配。
编辑
登录
后才能参与评论
