vector :: at与vector :: operator []

我知道这at()比[]它的边界检查要慢，因为边界检查也有类似的问题，例如C ++ Vector at / []运算符速度 或:: std :: vector :: at（）vs :: [] <<令人惊讶的结果！慢/快5到10倍！。我只是不明白该at()方法有什么用。

如果我有一个像这样的简单向量：std::vector<int> v(10);并且我决定通过使用at()而不是[]在有索引的情况下使用in 来访问其元素，i并且不确定其是否在向量范围内，它将迫使我用try-catch包装它块：

try
{
    v.at(i) = 2;
}
catch (std::out_of_range& oor)
{
    ...
}

尽管我可以自己使用size()和检查索引来获得相同的行为，但对我来说似乎更容易也很方便：

if (i < v.size())
    v[i] = 2;

所以我的问题是：与vector :: operator []
相比，使用vector :: at有什么优点？
什么时候应该使用vector :: at而不是vector :: size + vector :: operator []？

我想说vector::at()引发异常并不是真正被周围的代码捕获的。它们主要用于捕获代码中的错误。如果您需要在运行时进行边界检查（例如，索引来自用户输入），则最好使用一条if语句。因此，总而言之，设计您的代码时vector::at()要永远不会引发异常，这样，如果发生异常，并且程序中止，则表明存在错误。（就像一个assert()）

它迫使我用try-catch块包装它

不，不是的（try / catch块可以在上游）。当您希望引发异常而不是程序进入未定义的行为领域时，这很有用。

我同意大多数对向量的访问都是程序员的错误（在这种情况下，您应该使用它assert来更轻松地定位这些错误；大多数标准库的调试版本都会自动为您执行此操作）。您不想使用可以被上游吞没的异常来报告程序员错误：您希望能够修复该错误。

由于对向量的越界访问不太可能成为正常程序流程的一部分（在这种情况下，您是对的：事前检查size而不是让异常冒出来），我同意您的诊断：at本质上是没有用的。

与vector :: operator []相比，使用vector :: at有什么优点？什么时候应该使用vector :: at而不是vector :: size + vector :: operator []？

此处的重点是，异常允许将正常的代码流与错误处理逻辑分开，并且单个catch块可以处理由无数个抛出站点产生的问题，即使分散在函数调用内部也是如此。因此，这并不是说at()一次使用就一定会更容易，但是有时候，当您有大量要验证的索引时，它会变得更容易-并减少对正常情况逻辑的混淆。

还值得注意的是，在某些类型的代码中，索引以复杂的方式递增，并不断用于查找数组。在这种情况下，使用来确保正确检查要容易得多at()。

作为一个真实的例子，我有将C ++标记为词法元素的代码，然后还有其他将标记移到标记向量上的代码。根据遇到的情况，我可能希望增加并检查下一个元素，如下所示：

if (token.at(i) == Token::Keyword_Enum)
{
    ASSERT_EQ(tokens.at(++i), Token::Idn);
    if (tokens.at(++i) == Left_Brace)
        ...
    or whatever

在这种情况下，很难检查您是否不合适地到达了输入的末尾，因为这很大程度上取决于遇到的确切标记。在每个使用点进行显式检查是很痛苦的，随着前/后增量，使用点的偏移量，对某些较早测试的持续有效性的错误推理等等，程序员有更多的错误余地。

at 如果您有指向向量的指针，则可以更清楚：

return pVector->at(n);
return (*pVector)[n];
return pVector->operator[](n);

除了性能，第一个是更简单明了的代码。

首先，是否at()还是operator[]较慢没有规定。当没有边界错误时，我希望它们的速度差不多，至少在调试版本中是如此。区别在于，它at()指定了发生界限错误（异常）的确切情况，在这种情况下operator[]，就像的情况一样，它是未定义的行为-至少在以下情况下，我使用的所有系统（g ++和VC ++）都崩溃了使用正常的调试标志。（另一个区别是，一旦确定了我的代码，可以operator[] 通过关闭调试来大幅提高速度。如果性能要求，除非有必要，否则我不会这样做。）

在实践中，at()很少是合适的。如果上下文使您知道索引可能无效，则可能需要显式测试（例如，返回默认值或其他值），并且如果您知道它不可能无效，则要中止（如果您不知道它是否无效，建议您更精确地指定函数的接口。但是，也有一些例外，其中解析用户数据可能导致无效索引，并且该错误应导致整个请求中止（但不会使服务器停机）；在这种情况下，例外是适当的，at()它将为您做到这一点。

使用异常的全部要点是您的错误处理代码可能会更遥远。

在这种特定情况下，用户输入确实是一个很好的例子。假设您想从语义上分析XML数据结构，该结构使用索引来引用您内部存储在中的某种资源std::vector。现在XML树是一棵树，因此您可能想使用递归进行分析。在递归中，XML文件的编写者可能会发生访问冲突。在那种情况下，您通常希望突破所有递归级别，而只拒绝整个文件（或任何类型的“粗化”结构）。这是at派上用场的地方。如果文件有效，则只需编写分析代码即可。库代码将负责错误检测，您可以在粗糙级别上捕获错误。

同样，其他容器（如std::map）也具有std::map::at与std::map::operator[]：at 稍有不同的语义，可以在const映射上使用，而operator[]不能。现在，如果你想写容器无关代码，喜欢的事，可以处理任何const std::vector<T>&或者const std::map<std::size_t, T>&，ContainerType::at将是你的首选武器。

但是，所有这些情况通常在处理某种未经验证的数据输入时出现。如果可以确定应该有效的范围（通常应该如此），则通常可以使用和进行operator[]迭代，但更好的是。begin()end()

根据该文章，性能之外，它没有任何区别使用at或者operator[]，只有当访问是保证是向量的大小之内。否则，如果访问仅基于向量的容量，则使用会更安全at。

注意：似乎有些新人对这个答案不满意，而不必礼貌地告诉自己出了什么问题。以下答案是正确的，可以在此处验证。

实际上只有一个区别：at边界检查是否有，而边界检查operator[]没有。这不仅适用于调试版本，也适用于发行版本，并且由标准非常明确地指定。就这么简单。

这会使at方法变慢，但不建议使用它也是一个不好的建议at。您必须查看绝对数字，而不是相对数字。我可以肯定地说，您的大多数代码执行的操作都比花费更多at。就我个人而言，我尝试使用它at是因为我不想让讨厌的bug产生未定义的行为并潜入生产环境。