“noexcept” vs“Throws：nothing”

问题描述

在进行 C ++ 0x工作草案的最后一次修改时，我发现了很多

• 删除关键字 c>


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

这里有问题：

• /模式，当我们在Std-Lib中找到 noexcept 与 Throws：nothing ？


• 用户应该根据给定的规则得出特定的行为吗？也就是说
  在马德里，我们受到，其中包含以下指南：
  
  
  

  已采用的指南

  
  
  
  
  

  • 没有库析构函数应该抛出。

  
  

  • 应该标记每个具有广泛合同的库函数，LWG协议不能抛出，

  
  

  • 如果库交换函数，移动构造函数或移动赋值运算符是有条件的（即可以证明不会抛出应用noexcept运算符），则应将其标记为有条件的noexcept。没有其他函数应该使用条件noexcept规范。

  
  

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

  
  
  
  
  

  我不会将这些指南解释为必须针对更广泛的受众。这主要是承认我们确实有添加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“Throws：nothing”的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！