c – std :: move_if_noexcept的基本原理仍在移动投掷仅移动类型?

发布时间:2020-01-06 发布网站:大佬教程
大佬教程收集整理的这篇文章主要介绍了c – std :: move_if_noexcept的基本原理仍在移动投掷仅移动类型?大佬教程大佬觉得挺不错的,现在分享给大家,也给大家做个参考。
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;
        ... ...

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

简要地看一下,我会说投掷移动的类型不能放入矢量中,否则它可能不应该?

解决方法

我相信你已经很好地总结了委员会对于仅移动 – 禁止(假) – 类型的容器的选择.

>允许它们但具有基本的异常安全性,而不是强大的某些操作.
>在编译时禁止它们.

答:委员会绝对认为他们无法默默地将现有的C 03代码从具有强大的异常安全性转变为具有基本的异常安全性.

B.对于那些具有强大异常安全性的函数,委员会更倾向于让这些成员继续具有强大的异常安全性,即使对于尚不可能编写的代码(例如,用于操作仅移动类型的函数).

委员会意识到它可以完成上述两个目标,但B)中的情况除外,其中只有移动类型可能在移动施工期间抛出.这些情况仅限于向量IIRC的几个成员函数:push_back,reserve.注意,vector的其他成员已经只提供了基本的异常安全性(即使在C 98/03中),例如:赋值,插入(除非在末尾插入),擦除.

考虑到所有这些,委员会的决定应该是客户创建一个仅移动 – 无 – 除(错误)类型的向量,对于客户来说,将基本的强大异常安全性放松是更有用的(因为它已经是其他向量成员),而不是拒绝编译.

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

大佬总结

以上是大佬教程为你收集整理的c – std :: move_if_noexcept的基本原理仍在移动投掷仅移动类型?全部内容,希望文章能够帮你解决c – std :: move_if_noexcept的基本原理仍在移动投掷仅移动类型?所遇到的程序开发问题。

如果觉得大佬教程网站内容还不错,欢迎将大佬教程推荐给程序员好友。

本图文内容来源于网友网络收集整理提供,作为学习参考使用,版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ群:277859234,请注明来意。