异常保证和按值传递

我最近在多种情况下遇到过这个问题，其中表达的一些观点让我感到惊讶。这是第一个简单的例子：

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

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

再举一个涉及另一种异常保证类型的示例，请考虑：

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 不会提供强有力的保证，因为q在调用 g 之前不为空（记住std::move实际上并没有移动任何东西）。它可能会失败：参数评估的顺序未指定，因此可能首先构造 y 清空 q，然后构造 x 并抛出。即使从技术上讲它不是发生在函数体中，而是发生在调用函数的行为中，该函数仍然对此负责吗？

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

标准（5.2.2 函数调用 [expr.call] §4）规定参数初始化和销毁​​发生在调用函数的上下文中。所以是的，它is从技术上讲是洁净的声明f as noexcept.

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

还要考虑带有 const-ref 参数的函数：

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

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

x is noexcept好的。来电y然而不是，因为它包含一个（可能抛出）隐式转换。所以如果声明f as noexcept风格很糟糕，难道不应该这样说吗x?

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

关于第二个问题（强保证）... 我想说一个函数永远不能声明论点它被称为与。而且它永远不能对它的未来发生的事情做出声明参数如果它从未被真正调用过。

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

尽管我不一定同意强有力的保证——对于具有这样的签名的函数——应该包括这样的声明。 我什么would说的是：if这种声明对于强有力的保证具有任何实际意义是必要的，那么该函数不应该使用按值参数。

OTOH，如果这样的主张对于强有力的保证具有实际意义来说不是必要的，那么我认为我没有理由“禁止”它。例如。

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

IMO对该功能的“自然”有力保证是它要么附加所有元素b to a，或者，如果抛出异常，则离开a不变。我绝不会假设该保证包括任何有关所发生情况的索赔b。更不用说关于用于初始化的任何参数会发生什么的任何声明b.