本周小贴士#224：避免使用vector.at()

-飞鹤-

于 2024-03-28 18:10:32 发布

阅读量268

点赞数 1

CC 4.0 BY-SA版权

分类专栏： C++ Tips of the Week 文章标签： c++

原文链接：https://abseil.io/tips/224

C++ Tips of the Week 专栏收录该内容

77 篇文章

订阅专栏

本文围绕C++中at()方法展开，介绍其功能是返回指定位置元素引用并带边界检查，超出范围抛异常。分析了何时使用at()，指出在google3环境中其用途不大，还探讨了与未定义行为、关联容器及异常处理的关系，建议索引容器时采用更好方式。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

作为TotW#224是初发表于2023年8月24

作者：Titus Winters

更新于2024年1月24日

在Google3中没有vector::at()好的用途，在其他C++环境中也没有好的用途。这同样适用于其他随机访问序列中的at()，像protobuff中的RepeatedPrtFiled，以及optional以及absl::StatusOr等封装类型的value()。

at()在做什么？

at(size_type pos)的说明如下：
返回指定位置pos处的元素的引用，带有边界检查。如果pos不在容器的范围内，则抛出类型为std::out_of_range的异常。
这意味着我们可以将该方法的约定视为两个不同的行为：

检查pos >= size()，如果是，则抛出std::out_of_range异常。
否则，返回索引pos处的元素。
注意：规范没有直接处理代码传递负索引的情况，但是std::out_of_range也会为该情况抛出异常 —— 因为size_type是一个无符号整数类型，调用at(-5)将为pos产生一个非常大的正值。

何时使用at()?

由于at()方法的约定取决于边界检查逻辑，我们可以将其分为两种情况：要么我们通过构造已知索引是有效的，要么我们不知道。

如果我们已经知道序列足够大且查找将成功，则额外的边界检查是多余的。例如，大多数vector访问都是作为从0到size()的循环的一部分，我们已经知道操作将成功。因此，在已知边界检查将成功的情况下，更常见的是使用operator。

// 不好的写法
for (int i = 0; i + 1 < vec.size(); ++i) {
  ProcessPair(vec.at(i), vec.at(i + 1));
}

// 好的写法
for (int i = 0; i + 1 < vec.size(); ++i) {
  ProcessPair(vec[i], vec[i + 1]);
}

如果我们不知道序列是否足够大，那么抛出异常是正确处理的方式吗？通常来说不是。在google3构建中，抛出异常会导致程序终止。许多读者可能不会意识到一个像at()这样无害的的方法可能会导致进程存在终止的风险。

// 不好的写法
std::vector<absl::string_view> tokens = absl::StrSplit(user_string, ByChar(','));
LOG(INFO) << "Got leading token " << tokens.at(0);

// 更好的写法
std::vector<absl::string_view> tokens = absl::StrSplit(user_string, ByChar(','));
if (tokens.empty()) {
  return absl::InvalidArgumentError("Invalid user_string, expected ','");
}
// 或者如果终止程序优先项
std::vector<absl::string_view> tokens = absl::StrSplit(user_string, ByChar(','));
CHECK(!tokens.empty()) << "Invalid user_string "
                       << std::quoted(user_string)
                       << ", expected at least one ','";

因此，在google3环境中，at()方法的所有用法都不是真正有用的 —— 对于任何给定的用例，都存在更优的替代方案。

UB怎么样？

不幸的是，现实很少像“我们知道或者不知道”那样简洁：我们会犯错，代码也会随着时间的推移而改变，从而使最初正确的假设失效。鉴于人类是可犯错误的，我们可以想象一种使用at()的情况。具体来说，如果我们在使用at()时始终保持一致，即使我们出现严重崩溃（不好），也不会触发未定义行为（更糟）。

虽然我们认为“避免UB”是一个非常合理的目标，但我们仍然不赞成使用at()，主要是因为它与异常纠缠在一起的语义，如上所述。理想的解决方案是一个默认强化的operator[]运算符，在可以证明安全的情况下，通过编译器优化来去除边界检查。at()方法是对这个解决方案的糟糕近似。

相反，我们鼓励用户继续使用operator[]并通过其他方式减少面临UB的风险，包括：

如果您的项目负担得起，我们建议在产品中启用边界检查，可以使用HARDENING_ENABLE_SAFE_LIBCXX进行设置。目前的测量结果表明，这种加固的宏基准成本几乎没有统计学上的显著性。
如果您使用ASAN运行代码，如果访问了超出范围的元素，您还会得到诊断信息。

实际上，您的项目可能已经依赖了其中一些保护措施！

关于Map呢？

在Tip＃202中，我们讨论了在类似map和set的关联容器上使用at()的问题。总的来说，上面提到的错误处理逻辑适用：通常情况下，缺少键应该通过记录日志或返回错误来处理，而不是使进程崩溃。

然而，对于这些容器，"边界检查"开销的逻辑与std::vector的情况不同。对于std::vector，执行边界检查的计算成本与执行实际工作（返回指定的引用）的成本相似。对于关联容器，"边界检查"等效的操作是进行（必要的）查找，无论是树遍历、哈希等。

按照这种推理，当我们知道键已经存在（不会抛出异常），但无法保留迭代器或引用时，可能会使用at()来再次执行查找。这种情况非常罕见：请参阅Tip＃132以了解避免冗余映射查找的方法。

最终，在关联容器中使用at()的余地有点小。在这些情况下，比向量更多变化的空间。

那么C++中的异常处理呢？

在启用异常的环境中，关于at()的意见可能会稍有分歧。普遍来说，明确的边界检查通常比依赖于异常更好（性能更好，难以出错）。可以为防止UB采用多层防御的论点，但是很明显，这个习惯用法是operator而不是at()。

理想情况下，代码应该尽量少地对它所在的环境做出假设。根据将用于编译代码的工具链来推理代码往往是脆弱的。对于使用at()（或另一个基于异常的API）的正确性，它需要在两种不同的构建模式下都是正确的：终止整个进程必须是可接受的，并且在更高级别的代码中捕获异常并继续执行也必须是可接受的，因此库代码必须保持所有不变性。实际上，这意味着代码必须是异常安全的，而且任何对at()的超出范围的使用都可以终止进程。

我们在启用异常处理的环境中关于使用at()的最佳建议可能是，它通过减少潜在的UB来换取了隐藏的、通常是不必要的错误处理。这并不总是一个明确的权衡，但它似乎不大可能普遍值得付出成本。