7

move_if_noexcept将要：

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

我发现这相当令人惊讶，因为具有抛出 move-ctor 的仅移动类型仍将由使用move_if_noexcept.

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

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

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;
        ... ...

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

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

4

1 回答 1

6

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

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

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

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

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

委员会意识到它可以实现上述两个目标，除了 B) 中的情况，即仅移动类型可能在移动构建过程中抛出。这些情况仅限于vectorIIRC 的一些成员函数： push_back, reserve. 请注意，其他成员vector已经只提供了基本的异常安全性（即使在 C++98/03 中），例如：赋值、插入（除非在末尾插入）、擦除。

考虑到这一切，委员会的决定是，如果客户创建一个vectormove-only-noexcept(false) 类型，那么将强异常安全性放松到基本对客户来说会更有用（因为它已经是给其他vector成员的），而不是拒绝编译。

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

于 2013-11-06T20:46:33.390 回答