该noexcept关键字可以适当地应用于许多功能签名,但我不能确定何时我应该考虑在实践中使用它.根据我到目前为止所读到的内容,最后一分钟的添加noexcept似乎解决了移动构造函数抛出时出现的一些重要问题.但是,我仍然无法对一些实际问题提供令人满意的答案,这些问题使我首先要了解更多信息noexcept.
我知道永远不会抛出许多函数的例子,但编译器无法自行确定.noexcept在所有这些情况下我应该附加到函数声明吗?
不得不考虑我是否需要noexcept在每个函数声明之后追加,这将大大降低程序员的工作效率(坦率地说,这将是一个痛苦的屁股).对于哪些情况,我应该更加小心使用noexcept,以及在哪些情况下我可以使用暗示noexcept(false)?
我何时才能真实地期望在使用后观察到性能提升noexcept?特别是,给出一个代码示例,C++编译器在添加之后能够生成更好的机器代码noexcept.
就个人而言,我关心的是noexcept因为编译器提供了更大的自由来安全地应用某些类型的优化.现代编译器是否noexcept以这种方式利用?如果没有,我可以期待他们中的一些人在不久的将来这样做吗?
例如,有两种不同的方法来访问私有数组的元素,重载数组下标运算符或定义at:
T& operator[](size_t i) { return v[i]; }
T const& operator[](size_t i) const { return v[i]; }
T& at(size_t i)
{
if (i >= length)
throw out_of_range("You shall not pass!");
return v[i];
}
T const& at(size_t i) const
{
if (i >= length)
throw out_of_range("You shall not pass!");
return v[i];
}
Run Code Online (Sandbox Code Playgroud)
该at版本可以抛出异常,但数组下标运算符不能.
我的问题是,尽管operator[]没有抛出异常,它是否可以被标记为noexcept甚至知道它可以引发SIGSEGV信号,还是只是一种不好的做法?
我想指出一个信号(如SIGSEGV)也不例外.作为文字解释noexcept意义,一个noexcept功能是声称它不会抛出异常.它什么也没说(包括信号).
但是,noexcept函数具有更多的意义,至少对于我的代码的客户而言.noexcept也隐含地说这个函数是安全的,它会在没有计算错误的情况下完成它的执行.
那么,标记noexcept一个不安全的功能是不合适的呢?