move_if_noexcept将：
>返回一个右值 – 促进移动 – 如果移动构造函数是noexcept或者没有复制构造函数(仅移动类型)
>返回左值 – 强制复制 – 否则
我发现这个相当令人惊讶,因为只有移动类型的投掷移动器仍然会有使用move_if_noexcept的代码调用此移动器.
有没有给出一个彻底的理由呢？ (可能直接或在N2983之间？)
不编码会不会更好,而不是仍然不得不面对不可恢复的移动场景？ N2983中给出的矢量示例很好：
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;
... ...
标记线中给出的注释实际上是错误的 – 对于可以投掷移动构造的仅移动类型,当我们将旧元素移动到新位置时,实际上已经开始 – 可能失败 – 不可逆转的突变.
简要地看一下,我会说投掷移动的类型不能放入矢量中,否则它可能不应该？
解决方法
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?
我相信你已经很好地总结了委员会对于仅移动 – 禁止(假) – 类型的容器的选择.
>允许它们但具有基本的异常安全性,而不是强大的某些操作.
>在编译时禁止它们.
答：委员会绝对认为他们无法默默地将现有的C 03代码从具有强大的异常安全性转变为具有基本的异常安全性.
B.对于那些具有强大异常安全性的函数,委员会更倾向于让这些成员继续具有强大的异常安全性,即使对于尚不可能编写的代码(例如,用于操作仅移动类型的函数).
委员会意识到它可以完成上述两个目标,但B)中的情况除外,其中只有移动类型可能在移动施工期间抛出.这些情况仅限于向量IIRC的几个成员函数：push_back,reserve.注意,vector的其他成员已经只提供了基本的异常安全性(即使在C 98/03中),例如：赋值,插入(除非在末尾插入),擦除.
考虑到所有这些,委员会的决定应该是客户创建一个仅移动 – 无 – 除(错误)类型的向量,对于客户来说,将基本的强大异常安全性放松是更有用的(因为它已经是其他向量成员),而不是拒绝编译.
这只是客户端为C 11编写的新代码,而不是遗留代码,因为在C 11之前不存在仅移动类型.毫无疑问,C 11的教育者应该鼓励他们的学生写noexcept(true)移动成员.但是,具有基本异常安全保证的代码不是那么危险,也不是不寻常的,因此应该禁止它.毕竟,std :: lib已经充满了只带有基本异常安全保证的代码.
