6

重複の可能性:
STL アルゴリズムは、引数として .begin()、end() ではなくコンテナー全体を使用しますか?

私はいくつかのアルゴリズムを見てきましたが、それらのいくつかにコンテナを取り込むバリエーションがないのはなぜだろうかと思っています。

たとえばfind、コンテナと値を受け取ることができ、アルゴリズムは、コンテナのbeginandendを呼び出すことによってコンテナを内部的に反復処理できます。配列のサイズを最大要素数に変更する必要があるイテレータを要求する代わりにunique_copy、コンテナとアルゴリズムを使用する方が便利だと思われる場合と同じです。はそのような別の例です。push_backfor_each

私が知らない正当な理由があると確信していますか？

4

3 に答える 3

13

私が見ることができる2つの主な理由があります：

  1. コンテナにオーバーロードを追加すると、関数の数が2倍以上になります。1つの範囲だけを取るアルゴリズムごとに、オーバーロードは2倍になります。ただし、std::copy()2つの範囲がある場合、それぞれが独立して範囲（適切な抽象化はコンテナーではなく、レンジャーです）またはイテレーターのペアとして指定する必要があるため、すでに4つのオーバーロードになっています。
  2. 範囲が画像に入ると、何を返す必要があるかが完全には明確ではありません。あなたの例ではstd::find()、引数としてイテレータを取得すると、これが明らかにイテレータを返します。範囲が指定されている場合、実際には別の範囲を返す方がはるかに合理的です。さらに悪いことに、最初に単一のパス範囲（たとえば、ストリームから読み取るもの）がない限り、2つの異なる範囲、つまり、オブジェクトの検索を開始する範囲と、オブジェクトを検索して終了する範囲を選択することもできます。別の次元は、イテレータで区切られた範囲ではなく、選択された範囲のコピーを取得するという選択である可能性があります。

STLが最初に提案されたとき、そもそもCrazyTalkと見なされていました。範囲を適切に処理するためにワームの別の主要な缶を開くように人々を説得しようとすると、アイデア全体が簡単に消えてしまう可能性があります。すぐにフォローアップする質問は次のようになります。なぜこれが変更されなかったのですか？...そしてこの質問にも2つの答えがあります：

  1. ドラフト版は図書館ワーキンググループに提出したときに妥当であると考えられていましたが、私は変更されたインターフェースを提案していません。しかし、私が概説した提案は、大きな熱意を持って満たされませんでした。また、当時、私は自分が思い描いていたインターフェイスを実際にどのように実装するかを許容できる努力で理解していませんでした（C ++ 2011の機能を使用すると、その方法を知っています）。私はSTLの新しいインターフェースの説明を書き始めましたが、これでも不完全であり、最近これに取り組むのに時間をかけることができませんでした。
  2. 私の意見では、アルゴリズムは正しい方法ですが、多くの人は意図的にアルゴリズムを使用していません。アルゴリズムを呼び出すよりも操作を行うループを書く方が「読みやすい」と言われているため、人々がアルゴリズムの使用を置き換えたケースを見つけました。残念ながら、これは実際、関連する関数オブジェクトが恐ろしいだけであるため、場合によっては当てはまります。アルゴリズムを使用している人はほとんどいないように思われることを考えると、アルゴリズムを変更するインセンティブはほとんどないようです。
于 2012-09-16T01:14:58.883 に答える
2

イテレータを使用するアルゴリズムは、最も一般的な目的です。適切なパラメータを使用して標準アルゴリズムを呼び出す独自の便利な関数を作成することを妨げるものは何もありません。

于 2012-09-16T02:28:39.560 に答える
2

要素を事前に割り当てずに結果をコンテナーに入れたい場合は、挿入反復子を使用します。例えば：

std::vector<int> elements;
// ...
std::vector<int> uniqueElements;
std::unique_copy(elements.begin(), elements.end(),
    std::back_inserter(uniqueElements));
于 2012-09-16T01:57:24.480 に答える