C++ noexcept 用于不抛出异常但可能导致内存故障的函数

Question

例如，有两种不同的方法来访问私有(private)数组的元素是很常见的，重载数组下标运算符，或定义 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];
}

at 版本可以抛出异常，但数组下标运算符不能。

我的问题是，尽管 operator[] 不会引发异常，但是否可以将其标记为 noexcept 即使知道它可以引发 SIGSEGV 信号，或者是这只是一种不好的做法？

我想指出一个信号(如 SIGSEGV)也不异常(exception)。作为对 noexcept 含义的字面解释，noexcept 函数声称它不会抛出异常。它没有说明其他任何事情(包括信号)。

但是，noexcept 函数的意义远不止于此，至少对于我的代码的客户而言。 noexcept 还隐含地表示该函数是安全的，它将在没有计算错误的情况下完成其执行。

那么，将 noexcept 标记为不安全的函数是否不合适？

Answer 1

这是一个棘手的问题，并提出了 noexcept — what for? from Andrzej's C++ blog 中涵盖的一些关键问题。这就是说，我将尝试在这里引用最小值(强调我的):

In this post I would like to share my observation on where using noexcept really adds value. It is less often than what one might expect, and it does not have that much to do with throwing or not throwing exceptions. The conclusion surprises me a bit, and I hesitate to present it because it is counter to the advice I hear from people I consider authorities on the subject.

和:

Given this negative attitude to noexcept, can it be considered useful at all? Yes. The noexcept feature was introduced very late into C++11 to address one particular issue with move semantics. It has been described here by Douglas Gregor and David Abrahams.

然后他继续给出了一个不寻常的移动分配定义并争辩说我们真正想要传达的不是它不会抛出异常而是它不会失败，但这是一个非常困难的问题，但它是真实的意图:

[...]This is because the information that noexcept really is intended to convey is that the function never fails; not that it never throws! We can see above that a function can fail but still not throw, but it still qualifies for noexcept(false). Perhaps the keyword should have been called nofail. The never-fail guarantee cannot be checked by the compiler (much like any other failure-safety guarantee), therefore the only thing we can do is to declare it.

This is part of a more general observation, that what we are interested in is really failure safety in program components rather than exception safety. No matter if you use exceptions, error return values, errno or what

ever else, the reasoning about basic (no leak, invariant preserved), strong (commit or rollback) and never-fail guarantee should still hold.

因此，如果我们采取类似的立场，那么答案似乎是否定的，如果不适合使用 noexcept 并且这似乎是您的倾向。我不认为这是一个明确的答案。

他还注意到 proposal N3248: noexceptPrevents Library Validation .而这又是 N3279: Conservative use of noexcept in the Library 的基础。 .这篇论文定义了窄合约和宽合约，就像 N3248 一样:

Wide Contracts

A wide contract for a function or operation does not specify any undefined behavior. Such a contract has no preconditions: A function with a wide contract places no additional runtime constraints on its arguments, on any object state, nor on any external global state. Examples of functions having wide contracts would be vector::begin() and vector::at(size_type) . Examples of functions not having a wide contract would be vector::front() and vector::operator[](size_type) .

Narrow Contracts

A narrow contract is a contract which is not wide. Narrow contracts for a functions or operations result in undefined behavior when called in a manner that violates the documented contract. Such a contract specifies at least one precondition involving its arguments, object state, or some external global state, such as the initialization of a static object. Good examples of standard functions with narrow contracts are vector::front() and vector::operator[](size_type) .

并推荐:

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

并暗示具有窄合约的函数不应该是noexcept，由LWG issue 2337 支持。其中说:

[...]These design considerations override our general policy against noexcept for narrow-contract functions. [...]

因此，如果我们想保守一点并遵循标准库实践，那么似乎由于 operator[] 没有广泛的契约(Contract)，因此不应将其标记为 noexcept。