是否值得降低我的代码的可读性，以便在出现内存不足错误时提供异常安全性?

Is it worth making my code less readable for providing exception safety in case of out of memory errors?

本文关键字：错误 内存不足 安全性 异常 我的 值得 代码 可读性 是否      更新时间：2023-10-16

我有一个不可复制Item的游戏，因为它们应该是唯一的：

class Item {
Item() noexcept;
Item(Item&&) noexcept;
Item(Item const&) = delete;
// ...
};

class Creature能够接收Item并将其添加到他们的inventory：

void Creature::receive_item(Item&& item) noexcept {
this->inventory.push_back(std::move(item));
}
void caller_code() {
Creature creature;
Item item;
// ...
creature.receive_item(std::move(item));
}

这种方法看起来很好，很干净，但有一个小问题：如果我的代码的任何部分可以在std::bad_alloc后恢复，因此捕获了recieve_item()的push_back()抛出的一个，那么游戏中的逻辑是未定义的：一个Item被移动到一个函数，该函数存储了一个失败的函数，所以它只是丢失了。此外，必须删除noexcept说明符才能实现这种可能性。

因此，我可以以这种方式提供异常安全性(如果我错了，请指出(：

void Creature::receive_item(Item& item) {
this->inventory.resize(this->inventory.size() + 1);
// if it needs to allocate and fails, throws leaving the item untouched
this->inventory.back() = std::move(item);
}
void caller_code() {
Creature creature;
Item item;
// ...
creature.receive_item(item); // no moving
}

但是，现在我们有了新的缺点：

  • 调用方代码中缺少std::move()掩盖了移动item的事实;
  • "resize(+1("部分很丑陋，在代码审查期间可能会被误解。

问题在标题中。即使对于如此奇怪的情况，异常安全也被认为是一个好的设计吗？

问题的答案取决于您是否可以并且想要处理内存分配错误，而不是崩溃。如果你这样做，你将不得不实施措施，而不仅仅是捕捉std::bad_alloc.大多数现代操作系统都实现了内存过载，这意味着内存分配将成功，但首次访问分配的内存将导致页面错误，这通常会导致崩溃。在将指针返回给调用方之前，您必须显式错误分配的内存分配页面以检测内存不足情况。

关于代码修改，您不必修改对push_back的调用：

this->inventory.push_back(std::move(item));

如果push_back(或任何其他潜在的重新分配方法(需要分配新的缓冲区，它将在将新项移动到向量之前执行此操作。显然，这是因为向量中没有空间可以将新元素移动到。当重新分配缓冲区并将所有现有元素移动/复制到新缓冲区时，新元素将作为最后一步移动。

换句话说，如果抛出push_back，您可以确定新项目未被移动。如果它没有抛出并正常返回，则项目将从中移出。

相关文章：