" noexcept" vs“投掷：没有” [英] "noexcept" vs "Throws: nothing"

问题描述

在经过最后编辑的C ++ 0x工作草案时，我发现很多

• 删除关键字 noexcept


• 添加文字在同一个地方投掷：没有

，反之亦然。只是一些例子：

• 替换 noexcept 反对抛出： / strong>： 20.6.4指针安全[util.dynamic.safety] 模板< class T> T * undeclare_reachable（T * p）;


• 添加 noexcept ： 20.6.3.2 。指针特征成员函数[pointer.traits.functions] ：静态指针pointer_trait< T *> :: pointer_to（...）noexcept;

这里有问题：

• 是否有一般规则/ pattern，当我们在Std-Lib中发现 noexcept vs. 抛出：没有


• 用户是否应该根据给定的规则获得特定的行为？即当他们应该或不应该将 noexcept 添加到自己的函数中

解决方案

在马德里，我们受到 N3279 ，其中包括以下准则：

已通过指南

• 没有库析构函数应该抛出。他们将使用隐含提供的（非投掷）异常规范。




• 每个具有广泛合同的库函数（LWG同意不能抛出）都应该被标记如果一个库交换函数，移动构造函数或移动赋值运算符是有条件的（即可以被证明不会被抛出）应用noexcept运算符），那么它应该被标记为有条件地被忽略。没有其他功能应该使用条件noexcept规范。




• 设计用于与C代码（如原子设施）兼容的库函数可以标记为无条件地无效。

我不会将这些准则解释为必须针对更广泛的受众群体。这主要是承认我们确实存在向后兼容性问题，增加noexcept。如果我们错了，noexcept比在下一个标准中删除更容易添加。所以我们试图应用一个既保守又系统的noexcept。

While going through the last edits of the C++0x Working draft I found a lot of

• removal of the keyword noexcept
• addition of textual Throws: nothing at the same place

and vice versa. Just some examples:

• replacement of noexcept against Throws: nothing: 20.6.4 Pointer safety [util.dynamic.safety] template<class T> T*undeclare_reachable(T*p);
• addition of noexcept: 20.6.3.2. Pointer traits member functions [pointer.traits.functions]: static pointer pointer_trait<T*>::pointer_to(...) noexcept;

Questions here:

• Is there a general rule/pattern, when we will find noexcept vs. Throws: nothing in the Std-Lib?
• Should users derive a specific behavior by that given rule? I.e. when they should or should not add noexcept to their own functions?

解决方案

In Madrid we were strongly influenced by N3279 which includes the following guidelines:

Adopted Guidelines

• No library destructor should throw. They shall use the implicitly supplied (non- throwing) exception specification.

• Each library function having a wide contract, that the LWG agree cannot throw, should be marked as unconditionally noexcept.

• If a library swap function, move-constructor, or move-assignment operator is conditionally-wide (i.e. can be proven to not throw by applying the noexcept operator) then it should be marked as conditionally noexcept. No other function should use a conditional noexcept specification.

• Library functions designed for compatibility with "C" code (such as the atomics facility), may be marked as unconditionally noexcept.

I would not interpret these guidelines as necessarily targeting a wider audience. This is mainly an admission that we do have backward compatibility concerns with adding noexcept. If we get it wrong, noexcept is easier to add than to remove in the next standard. So we attempted an application of noexcept that was both conservative and systematic.

这篇关于" noexcept" vs“投掷：没有”的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！