std::move_if_noexcept 仍然移动投掷仅移动类型的基本原理

Rationale for std::move_if_noexcept still moving throwing move-only types?

本文关键字：移动 类型 noexcept if move std      更新时间：2023-10-16

move_if_noexcept将：

  • 返回一个右值 -- 便于移动 -- 如果移动构造函数noexcept或没有复制构造函数（仅移动类型）
  • 返回一个左值 - 强制复制 - 否则

我发现这相当令人惊讶，因为具有抛掷移动 ctor的仅移动类型仍将由使用 move_if_noexcept 的代码调用此移动 ctor。

对此有没有给出详尽的理由？（也许直接或在 N2983 的行之间？

代码不编译而不是仍然不得不面对无法恢复的移动场景不是更好吗？N2983 中给出的vector示例很好：

void reserve(size_type n)
{
  ... ...
                 new ((void*)(new_begin + i)) value_type( std::move_if_noexcept( (*this)[i]) ) );
        }
        catch(...)
        {
            while (i > 0)                 // clean up new elements
               (new_begin + --i)->~value_type();
            this->deallocate( new_begin );    // release storage
            throw;
        }
*!*     // -------- irreversible mutation starts here -----------
        this->deallocate( this->begin_ );
        this->begin_ = new_begin;
        ... ...

标记行中给出的注释实际上是错误的 - 对于可以抛出移动构造的仅移动类型，当我们将旧元素移动到新位置时，可能失败的不可逆突变实际上已经开始。

简单地看一下，我会说投掷移动类型不能放入矢量中，但也许不应该？

简单地看一下，我会说一个只有投掷动作的类型不能 否则被放入向量中，但也许不应该？

我相信你已经很好地总结了委员会对仅移动-noexcept（false）类型的容器的选择。

  1. 允许它们，但基本例外是安全，而不是某些操作的强。
  2. 在编译时禁止它们。

一个。委员会绝对认为，他们不能默默地将现有的 C++03 代码从具有强大的异常安全性更改为具有基本的异常安全性。

二. 对于那些具有强异常安全性的函数，委员会更希望这些成员继续具有强大的异常安全性，即使对于还不可能编写的代码（例如，对于操作仅移动类型的函数）。

委员会意识到它可以实现上述两个目标，除了B）中的情况，即在移动构造期间，仅移动类型可能会抛出。 这些情况仅限于IIRC vector几个成员职能：push_back、reserve。 请注意，vector的其他成员已经只提供基本的异常安全（即使在 C++98/03 中），例如：分配、插入（除非在末尾插入）、擦除。

考虑到所有这些，委员会的决定是，如果客户端创建仅移动-noexcept（false）类型的vector，则对客户端来说，将强异常安全性放宽到基本（因为它已经用于其他向量成员）比拒绝编译更有用。

这只会是客户端为 C++11 编写的新代码，而不是旧代码，因为仅移动类型在 C++11 之前不存在。 毫无疑问，C++11的教育工作者应该鼓励他们的学生写noexcept（真正的）move成员。 然而，具有基本例外安全保证的代码并不那么危险，也不罕见，以至于应该被禁止。 毕竟，std：：lib 已经充满了只带有基本异常安全保证的代码。

相关文章：