![](/img/trans.png)
[英]std::move_if_noexcept calls copy-assignment even though move-assignment is noexcept; why?
[英]Does disabling support for exceptions also disable support for `std::move_if_noexcept`?
一些商店(例如,一些视频游戏开发团队)在其构建环境中禁用对异常的支持。 在禁用异常的情况下,开发人员没有理由声明他们的移动操作noexcept
(假设这样的代码甚至可以编译)。 但是标准库实现应该在实现某些操作时调用std::move_if_noexcept
(例如, std::vector::push_back
)。 标准库实现通常在编译期间检查以查看是否禁用了异常,如果是,则使用std::move
而不是std::move_if_noexcept
? 当禁用异常时,编译器会导致std::is_nothrow_move_constructible
为所有类型返回true吗? 或者禁用异常支持会产生意外的副作用std:move_if_noexcept
无法启用移动操作?
我对实践中发生的事情很感兴趣。 我知道禁用异常支持会使我们脱离C ++标准的范畴。
在启用或不启用异常的情况下,此代码在GCC 4.9和clang 3.5上输出false true false true
:
void foo() {}
void bar() noexcept {}
void foo2() noexcept(noexcept(foo())) {}
void bar2() noexcept(noexcept(bar())) {}
int main() {
std::cout << std::boolalpha << noexcept(foo()) << ' ' << noexcept(bar())
<< ' ' << noexcept(foo2()) << ' ' << noexcept(bar2()) << std::endl;
}
所以看起来noexcept
行为至少对这两个编译器来说并不依赖于编译器选项。
更新:VS2013 根本不支持noexcept
。
-fnothrow-opt将throw()异常规范视为noexcept规范,以减少或消除相对于没有异常规范的函数的文本大小开销。 如果函数具有带有非平凡析构函数的类型的局部变量,则异常规范实际上使函数变小,因为可以优化这些变量的EH清理。 语义效果是从具有这种异常规范的函数抛出的异常导致调用终止而不是意外。
所以根据gcc文档的throw函数变成noexcept规范。
这应该意味着更多的对象将返回true而不是更少
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.