c++ - std::move_if_noexcept 的基本原理仍在 move 抛出仅 move 类型？

Question

move_if_noexcept将:

• 返回一个右值——促进 move ——如果 move 构造函数是noexcept或者如果没有复制构造函数(仅 move 类型)
• 返回一个左值——强制复制——否则

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

是否对此给出了详尽的理由？ (也许直接或在 N2983 的两行之间？)

代码不编译而不是仍然不得不面对不可恢复的 move 场景会不会更好？ 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;
        ... ...

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

简单地看一下，我会说只能 throw 的类型不能放入 vector 中，但也许不应该？

Answer 1

Looking at it briefly, I'd say that a throwing move-only type couldn't be put into a vector otherwise, but maybe it shouldn't?

我相信您已经很好地总结了委员会对 move-only-noexcept(false) 类型容器的选择。

1. 允许它们，但对某些操作具有基本的异常安全性而不是强异常。
2. 在编译时禁止它们。

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

B.对于那些具有强异常安全性的函数，委员会更希望让这些成员继续具有强异常安全性，即使是对于可能尚未编写的代码(例如，用于操作仅 move 类型的函数)也是如此。

委员会意识到它可以实现上述两个目标，但 B) 中的情况除外，在这种情况下，仅 move 类型可能会在 move 构造期间抛出。这些情况仅限于 vector IIRC 的几个成员函数:push_back、reserve。请注意，vector 的其他成员已经仅提供基本的异常安全性(即使在 C++98/03 中)，例如:赋值、插入(除非在末尾插入)、删除。

考虑到所有这些，委员会的决定是，如果客户创建一个 move-only-noexcept(false) 类型的 vector，这对客户更有用将强异常安全放宽到 basic(因为它已经对其他 vector 成员)，而不是拒绝编译。

这只是客户端为 C++11 编写的新代码，而不是遗留代码，因为在 C++11 之前不存在仅 move 类型。毫无疑问，C++11 的教育者应该鼓励他们的学生编写 noexcept(true) move 成员。然而，具有基本异常安全保证的代码并没有那么危险，也没有异常，以至于应该被禁止。毕竟，std::lib 已经塞满了仅带有基本异常安全保证的代码。