有自动noexcept说明符吗？ [英] Is there an automatic noexcept specifier?

问题描述

我听说 noexcept 关键字更像是它不应该抛出异常，而不是它不会。

I've heard that noexcept keyword is more like 'it should never throw an exception' rather than 'it doesn't'.

我不认为使用 noexcept 关键字不好，如果我不确定它是否抛出异常，但 noexcept 关键字有时与一个移动构造函数中的性能相关。

I don't think it's good to use noexcept keyword if I'm not sure it throws an exception or not, but noexcept keyword is sometimes related to the performance like in a move constructor.

所以我试图使用 noexcept 限定符，但如果它在定义中有多个语句，它变得更加困难，它变成一种复制和粘贴的东西。

So I tried to use noexcept qualifiers, but it gets harder if it has multiple statements in the definition and it becomes a kind of copy-and-paste thing.

template <class T>
void f(T&& t)
    noexcept(noexcept(statement_1) &&
             noexcept(statement_2) &&
             noexcept(statement_3) &&
             noexcept(statement_4) &&
             noexcept(statement_5))
{
    statement_1;
    statement_2;
    statement_3;
    statement_4;
    statement_5;
}

我认为编译器可以确定函数的定义是否由非 - 如果存在 noexcept（auto）的表达式，那么使用 noexcept 似乎在标准中没有这样的东西。

I think the compiler can figure out whether the definition of a function consists of non-throwing statements, so it will be easier to utilize noexcept if there's an expression like noexcept(auto), but it seems that there is no such thing in the standard.

有没有办法简化noexcept表达式？

Is there any way to simplify the noexcept expression?

推荐答案

目前没有。但是，有一个关于该主题的提案，提出 noexcept（auto）语法： http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4473
根据Botond Ballo的旅行报告：Lenexa的C ++标准会议，2015年5月，此提案的状态是需要进一步的工作 https://botondballo.wordpress.com/2015/06/05/trip-report-c-standards -meeting-in-lenexa-may-2015 /

Currently there is none. There is, however, a proposal on that topic, which proposes noexcept(auto) syntax: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4473 The status of this proposal is "needs further work", according to Botond Ballo's "Trip Report: C++ Standards Meeting in Lenexa, May 2015" https://botondballo.wordpress.com/2015/06/05/trip-report-c-standards-meeting-in-lenexa-may-2015/

进一步的工作。提案的方向是有希望的，但它不是足够好，或有一个或多个设计点的具体问题。鼓励作者返回修改后的提案，更加充实和/或解决所述问题。

Further Work. The proposal’s direction is promising, but it is either not fleshed out well enough, or there are specific concerns with one or more design points. The author is encouraged to come back with a modified proposal that is more fleshed out and/or addresses the stated concerns.

...

noexcept（auto），这基本上意味着从它调用的函数的noexceptable推导出这个函数的noexcept-像返回类型推导一样，这需要在使用函数的每个翻译单元中可用的函数体。它被提出，连同提出异常规范类型系统的一部分，这意味着修改函数的主体可以改变函数的类型（类似于返回类型的扣除），但人们并不过分担心

noexcept(auto), which basically means "deduce the noexcept-ness of this function from the noexcept-ness of the functions it calls. Like return type deduction, this requires the body of the function being available in each translation unit that uses the function. It was brought up that, together with the proposal for making exception specifications part of the type system, this would mean that modifying the function’s body could change the function’s type (again similarly to return type deduction), but people weren’t overly concerned about that.

这篇关于有自动noexcept说明符吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！