移动语义是否不完整？

Question

在复制效率低下的情况下，移动语义取代了复制语义。复制语义完全处理可复制对象，包括 const 对象。

c++11 中已经存在无数不可复制的对象，例如 std::unique_ptr。这些对象完全依赖于移动语义，因为从一个对象移动允许使其无效。这对于像 RAII 这样的流行设计模式很重要（恕我直言）。

将 const 不可复制对象分配给内存区域时会出现问题。这样的对象无法以任何方式恢复。

这在对象的生命周期中显然很重要，因为它是常量。然而，在它的生命周期结束时，当调用析构函数时，（不存在的）对象是短暂的非常量。

我建议 moving 析构函数可能是移动语义模型的一个有价值的补充。

考虑一个在 unordered_set 中使用 unique_ptr 的简单情况。您可以使用移动构造函数（或构造“emplace”）将insert 放入此集合，但是如果您想将此指针移动到另一个 unordered_set（即保持它为常量），这是不可能的。

必不可少，有iterator insert((possibly const) key&&)，但没有const key&& erase(iterator)。事实上这是不可能的。容器只能被扩展为返回一些指向键的指针，然后忘记它。

一个移动的析构函数可以解决这个问题，即const MyClass&& ~MyClass()，因为它只会在析构过程中违反 const（当编译器认为对象仍然无效时）。

编辑：我应该指出const MyClass&& ~MyClass() const 实际上更有意义。析构函数不必修改任何内容，只需将对象销毁，就好像它不再是它所控制的任何资源的有效句柄一样。

Answer 1

对不起，前提是有缺陷的。

unordered_set 实际上并不包含 const 对象。它只是不给你写访问包含的元素。这只是访问器的属性。

可以添加一个key erase(iterator) 函数，它只是将元素移出到一个临时位置。我不知道你为什么想要一个key&&。

至于const MyClass&& ~MyClass() const，由于三个原因，这没有意义：dtor 既没有返回类型也没有 CV 分类，也没有为它们完成重载解析。

Answer 2

恕我直言，您已经确定了真正的需求。

您的解决方案听起来很像我所说的破坏性移动语义。在original move semantics proposal 中描述了这种可能性。我认为这样的设计是可能的，尽管它并非没有问题。据我所知，没有人在标准委员会从事这一领域的工作。

有一些更简单的方法可以从不需要更改语言的关联容器中提取仅移动类型（除了可能允许在没有未定义行为的情况下进行类型双关）。

N3645 是一个仅限库的提案，它将嵌套的 node_ptr 类型放入每个容器中。 node_ptr 很像 unique_ptr。它具有关联容器中节点的唯一所有权。但是，当您取消引用它时，您将获得对节点中 value_type 的非常量访问，而不是节点本身。 extract 和 insert 成员被添加到关联容器中，允许在容器中插入和删除节点（由 node_ptr 拥有）。

您可以使用它从容器中删除节点，然后将仅移动类型移出节点，并在完成后让~node_ptr() 清理节点。本文包含此示例来演示此功能：

set<move_only_type> s;
s.emplace(...);
move_only_type mot = move(*s.extract(s.begin())); // extract, move, deallocate node

注意s.extract 是noexcept，当然~node_ptr() 也是。如果move_only_type的移动构造是noexcept，那么整个操作就是noexcept。否则，如果移动构造抛出，set 将被留下，就好像该项目已从 set 中删除一样。

目前，N3645 没有任何进展。它尚未被投票纳入工作草案，我不相信它会成为。

更新 C++17

我的立场是正确的：我上面描述的功能是用P0083R3 投票进入 C++17 的。感谢 Cosme 在下面的 cmets 中提醒我这一点。

Answer 3

所以基本上你是说应该可以将const 对象移动到另一个const 对象并销毁原始对象？

抱歉，我认为将其设为const 的全部要点是为了防止这种情况发生。

否则会形成一个漏洞：你可以将const 对象从其内存位置销毁，然后将const 对象销毁-移动到第一个内存位置一个（通过展示位置new）。

现在对象已经改变了，即使它是const...所以基本上const 是无用的。

见下面的 cmets...