vector :: atとvector :: operator []

私はそれat()が[]その境界チェックのために遅いことを知っています、それは同様にC ++ Vector at / []オペレーター速度 または:: std :: vector :: at（）対operator []のような同様の質問で議論されます<<驚くべき結果!! 5〜10倍遅い/速い！。私at()はその方法が何に適しているのか理解できません。

このような単純なベクトルがある場合：インデックスがあり、ベクトルが境界にあるかどうかわからない状況ではなく、std::vector<int> v(10);を使用してその要素にアクセスすることにした場合、try-catchで強制的にラップするブロック：at()[]i

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

私はsize()自分でインデックスを使用して確認することで同じ動作を得ることができますが、これは私にとってより簡単で非常に便利です：

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

だから私の質問は：vector :: operator []よりvector :: at
を使用する利点は何ですか？
いつvector :: size + vector :: operator []ではなくvector :: atを使用すればよいですか？

vector::at()スローする例外は、すぐ近くにあるコードによってキャッチされることを実際には意図していないと思います。これらは主に、コード内のバグを見つけるのに役立ちます。たとえば、インデックスがユーザー入力から取得されるため、実行時に境界チェックが必要な場合は、ifステートメントを使用するのが最善です。したがって、要約するvector::at()と、例外をスローしないことを意図してコードを設計します。そうすると、例外がスローされてプログラムが異常終了する場合、それはバグの兆候です。（のようにassert()）

強制的にtry-catchブロックでラップする

いいえ、ありません（try / catchブロックを上流にすることができます）。プログラムではなく例外をスローして、未定義の動作領域に入るようにする場合に役立ちます。

私は、ベクトルへの範囲外のアクセスのほとんどがプログラマーのミスであることにも同意します（その場合、assertそれらのミスをより簡単に見つけるために使用する必要があります。標準ライブラリのほとんどのデバッグバージョンがこれを自動的に行います）。プログラマのミスを報告するために上流で飲み込むことができる例外を使用したくない：バグを修正できるようにしたい。

ベクトルへの境界外のアクセスが通常のプログラムフローの一部である可能性は低いため（そうである場合は、あなたが正しい：size例外をバブルアップさせるのではなく、事前に確認してください）、診断に同意します。at本質的に役に立たない。

vector :: operator []よりvector :: atを使用する利点は何ですか？いつvector :: size + vector :: operator []ではなくvector :: atを使用すればよいですか？

ここで重要な点は、例外により、通常のコードフローをエラー処理ロジックから分離できることと、関数呼び出し内に分散していても、単一のcatchブロックが無数のスローサイトから生成された問題を処理できることです。そのat()ため、1回の使用では必ずしも簡単ではありませんが、検証するインデックスが大量にあると、通常のケースのロジックがわかりやすくなり、わかりやすくなります。

また、一部のタイプのコードでは、インデックスが複雑な方法で増分され、配列を検索するために継続的に使用されていることも注目に値します。そのような場合、を使用して正しいチェックを確実にする方がはるかに簡単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 ++）でのクラッシュ、少なくとも通常のデバッグフラグが使用されます。（もう1つの違いは、コードを確認したらoperator[] 、デバッグをオフにすることで速度が大幅に向上することです。パフォーマンスに必要な場合は、必要でない限り実行しません。）

実際にat()は、めったに適切ではありません。コンテキストが、インデックスが無効である可能性があることがわかっている場合は、おそらく明示的なテスト（たとえば、デフォルト値などを返す）が必要であり、無効にできないことがわかっている場合は、中止する必要があります（それが無効であるかどうかわからないので、関数のインターフェイスをより正確に指定することをお勧めします）。ただし、いくつかの例外はありますが、無効なインデックスがユーザーデータの解析に起因する場合があり、エラーによって要求全体が中止されます（ただし、サーバーはダウンしません）。そのような場合、例外が適切であり、それat()を行います。

例外を使用する重要な点は、エラー処理コードがさらに離れている可能性があることです。

この特定のケースでは、ユーザー入力は確かに良い例です。XMLのデータ構造を意味的に分析して、インデックスを使用して内部でに格納しているある種のリソースを参照するとしstd::vectorます。これでXMLツリーはツリーになりました。おそらく、再帰を使用してそれを分析したいと思うでしょう。深いところにある再帰では、XMLファイルの作成者によるアクセス違反が発生する可能性があります。その場合、通常、再帰のすべてのレベルから出て、ファイル全体（またはあらゆる種類の「粗い」構造）を拒否するだけです。これが便利なところです。ファイルが有効であるかのように、分析コードを記述するだけです。ライブラリー・コードがエラー検出を処理し、大まかなレベルでエラーをキャッチできます。

また、他のコンテナは、のようにstd::map、また持っているstd::map::atよりもわずかに異なる意味を持っているstd::map::operator[]：一方で、constのマップに使用することができますではoperator[]できません。ここで、const std::vector<T>&またはのいずれかconst std::map<std::size_t, T>&に対処できるようなコンテナにとらわれないコードを記述しContainerType::atたい場合は、武器を選択します。

ただし、通常、これらのケースはすべて、ある種の未検証のデータ入力を処理するときに発生します。あなたの有効範囲について確信している場合は、通常あるべきように、あなたは、通常使用することができoperator[]ますが、いっそのこと、とイテレータbegin()とend()。

この記事によると、パフォーマンスはさておき、ator を使用しても違いはありません。operator[]アクセスがベクターのサイズ内であることが保証されている場合のみです。それ以外の場合、アクセスがベクトルの容量のみに基づいている場合は、使用する方が安全atです。

注：一部の新しい人々は、何が悪いのかを知らせる礼儀なく、この回答に反対票を投じているようです。以下の答えは正しく、ここで確認できます。

実際には1つだけ違いがあります。at境界チェックをoperator[]行うのにそうではありません。これは、リリースビルドだけでなくデバッグビルドにも適用されます。これは、標準で非常に明確に指定されています。とても簡単です。

これによりatメソッドが遅くなりますが、を使用しないことも非常に悪いアドバイスatです。相対数ではなく、絶対数を調べる必要があります。あなたのコードのほとんどが、よりもはるかに高価な操作をしていることは間違いありませんat。個人的に、at未定義の動作を作成して本番環境に忍び込む厄介なバグが欲しくないので、使用を試みます。