异常保证和按值传递

Question

我最近在几种情况下遇到过这个问题，对此表达的一些意见让我感到惊讶。这是第一个简单的例子：

void f(std::vector<double> x) {};

问题是：是否可以记录或描述f 提供不抛出保证？同样，我怀疑由于异常不是从 f 的主体生成的，因此使用 noexcept 在技术上是合乎情理的。但是应该标记它noexcept 吗？例如，set 的优化版本以某种方式发现添加模板化比较器不得抛出的要求很有用。它在编译时使用静态断言检测到这一点并导致错误。然而，有人可以为取值的向量编写一个比较器，并将其标记为 noexcept，并将其与此版本的 set 一起使用。如果这会导致不良行为，那是容器作者的错吗？还是标记比较器noexcept的人？

再举一个涉及另一种异常保证的例子，考虑：

void g(std::vector<double> x, std::unique_ptr<int> y);

这个功能能否提供强有力的保证？

std::vector<double> p{1.0, 2.0};
auto q = std::make_unique<int>(0);
bool func_successful = true;

try {
  g(p, std::move(q));
}
catch (...) {
  func_successful = false;
}

if (!func_successful)
  assert(q);

我会争辩说，如果断言可能失败，那么 g 不提供强有力的保证，因为在调用 g 之前q 不是空的（记住std::move 实际上并没有移动任何东西）。它可能会失败：参数评估的顺序未指定，因此可以先构造 y 清空 q，然后构造 x 并抛出。即使它在技术上不是发生在体内，而是在调用函数的行为中，函数是否仍然对此负责？

编辑：我要提到 Herb Sutter 在这里谈论这个问题：https://youtu.be/xnqTKD8uD64?t=1h11m56s。他说标记这样的函数 noexcept 是“有问题的”；希望得到更详细的答复。

Answer 1

标准（5.2.2 函数调用 [expr.call] §4）说参数初始化和销毁​​发生在调用函数的上下文中。所以是的，从技术上讲，将f 声明为noexcept 是合乎道德的。

这确实是有道理的，即使它一开始是违反直觉的。 f 可以使用右值调用，在这种情况下，move-ctor 将用于初始化参数，因此即使调用函数的整个构造（包括参数设置和拆卸）仍然是 noexcept。或者 f 可以用空向量调用，在这种情况下，整个构造仍然有效地是 noexcept - 至少在我认为“合理”的库实现的情况下。

同时考虑带有 const-ref 参数的函数：

void x(std::string const&) noexcept {}

void y() noexcept
{
    x("foo");
}

x 是noexcept 好吧。但是，y 中的调用不是，因为它包含一个（可能抛出的）隐式转换。因此，如果将f 声明为noexcept 是不好的风格，那么x 是否也必须这样说？

所以我认为 C++ 程序员应该做以下两件事之一：不使用也不依赖 noexcept 规范，或者内化规则并始终对他们在调用站点所做的事情感到厌倦。

---

关于第二个问题（强力保证）... 我想说一个函数永远不能声称它被调用的 arguments。此外，如果它从未真正被调用过，它也永远无法声明其可能的参数会发生什么。

如果您心目中的强保证包括此类声明，那么我同意该功能不能提供这种强保证。

虽然我不一定同意强有力的保证——对于具有这样签名的函数——应该包括这样的声明。 我要说的是：如果这样的声明对于强保证具有任何实际意义是必要的，那么函数不应该使用按值参数。 p>

OTOH，如果这样的声明对于强有力的保证来说不是必要的，那么我认为我没有理由“禁止”它。例如

void StrongAppendAll(std::vector<T>& a, std::vector<T> b);

IMO 对此函数的“自然”强有力的保证是 它将b 中的所有元素附加到a，或者，如果抛出异常，则保持a 不变。我永远不会假设保证包括任何关于b 发生情况的索赔。更不用说关于初始化b的任何参数会发生什么。

Answer 2

问题是：将 f 记录或描述为提供不抛出保证是否可以接受？

C++ 标准不相信它是。考虑它在应用于作业时对 nothrow 的处理。

is_assignable 为真，如果对于T 和U，此表达式有效：std::declval<T>() = std::declval<U>()。 is_nothrow_assignable 为真，如果该表达式 全部为 noexcept。复制/移动分配也是如此（显然具有相同的类型）。

operator= 参数的初始化是表达式的一部分。因此，如果该初始化可以抛出，则分配不是 nothrow。有一个working group paper discussing this matter in some depth（主要围绕移动分配）。

是否应该标记此功能noexcept 是另一回事。但是一个函数只是 noexcept 不应该与函数调用表达式的某些部分永远不会抛出的信念相混淆。

我个人对此事的感觉是，您不应该一开始就标记随机函数noexcept。您应该将它们与特殊的成员函数和您明确需要 使用它的其他非常具体的地方一起使用。也就是说，它应该不仅仅是用户的语义标记。当某人实际上要进行元编程并根据是否为noexcept 来选择调用或不调用该函数时，请使用noexcept。