すべての<algorithm>関数がコンテナーではなく範囲のみを取得するのはなぜですか？

には多くの便利な関数がありますが<algorithm>、それらはすべて「シーケンス」、つまりイテレータのペアで動作します。たとえば、コンテナがあり、そのstd::accumulate上で実行したい場合、次のように書く必要があります。

std::vector<int> myContainer = ...;
int sum = std::accumulate(myContainer.begin(), myContainer.end(), 0);

私がやろうとしているのは：

int sum = std::accumulate(myContainer, 0);

私の目では、これはもう少し読みやすく、はっきりしています。

コンテナの一部のみを操作したい場合があるかもしれないので、範囲を渡すオプションがあることは間違いなく便利です。しかし、少なくとも私の経験では、それはまれな特別なケースです。私は通常、コンテナ全体を操作したいと思うでしょう。

これは、コンテナとのコールを取るラッパー関数書くのは簡単だbegin()し、end()その上に、このような便利な機能が標準ライブラリに含まれていません。

このSTL設計の選択の背後にある理由を知りたい。

...範囲を渡すオプションがあることは間違いなく便利です。しかし、少なくとも私の経験では、それはまれな特別なケースです。私は通常、コンテナ全体を操作したいと思うでしょう

あなたの経験ではまれな特別なケースかもしれませんが、実際にはコンテナ全体 が特別なケースであり、任意の範囲は一般的なケースです。

現在のインターフェイスを使用してコンテナケース全体を実装できることに気づきましたが、逆はできません。

そのため、ライブラリ作成者は、2つのインターフェースを事前に実装するか、すべてのケースをカバーする1つのインターフェースのみを実装するかを選択できました。

コンテナを取得してbegin（）およびend（）を呼び出すラッパー関数を書くのは簡単ですが、そのような便利な関数は標準ライブラリには含まれていません

特に、無料の機能が含まれてstd::beginおりstd::end、現在含まれています。

したがって、ライブラリが便利なオーバーロードを提供するとしましょう。

template <typename Container>
void sort(Container &c) {
  sort(begin(c), end(c));
}

また、比較ファンクタを使用して同等のオーバーロードを提供する必要があり、他のすべてのアルゴリズムに同等のオーバーロードを提供する必要があります。

しかし、少なくともフルコンテナで操作したい場合はすべてカバーしましたよね？まあ、そうではありません。検討する

std::for_each(c.rbegin(), c.rend(), foo);

コンテナの逆方向の操作を処理する場合は、既存のアルゴリズムごとに別のメソッド（またはメソッドのペア）が必要です。

したがって、範囲ベースのアプローチは、単純な意味でより一般的です：

• コンテナ全体のバージョンでできることはすべて実行できます
• コンテナ全体のアプローチは、必要なオーバーロードの数を2倍または3倍にしますが、それでもなお強力ではありません。
• 範囲ベースのアルゴリズムも構成可能です（反復子アダプターをスタックまたはチェーンできますが、これは関数型言語とPythonでより一般的に行われます）

もちろん、別の正当な理由があります。それは、STLを標準化するためにすでに多くの作業が行われていたことです。興味のある方は、Stepanov＆Leeの技術レポートをここで見つけることができます

コメントで述べたように、Boost.Rangeは標準への変更を必要とせずに新しいアプローチを提供します。

このまさに主題についてのハーブサッターによる記事があることがわかります。基本的に、問題はオーバーロードのあいまいさです。次の場合：

template<typename Iter>
void sort( Iter, Iter ); // 1

template<typename Iter, typename Pred>
void sort( Iter, Iter, Pred ); // 2

以下を追加します。

template<typename Container>
void sort( Container& ); // 3

template<typename Container, typename Pred>
void sort( Container&, Pred ); // 4

適切に区別するのが難しく4なり1ます。

提案されているが、最終的にC ++ 0xに含まれていない概念はそれを解決し、を使用してそれを回避することもできenable_ifます。一部のアルゴリズムでは、まったく問題ありません。しかし、彼らはそれに反対しました。

ここですべてのコメントと回答を読んだ後、rangeオブジェクトが最善の解決策だと思います。私は見てみると思いますBoost.Range。

基本的にレガシーの決定。イテレーターの概念はポインターでモデル化されていますが、コンテナーは配列ではモデル化されていません。さらに、配列は渡すのが難しいので（長さには一般に型のないテンプレートパラメーターが必要です）、多くの場合、関数はポインターのみを使用できます。

しかし、ええ、後知恵では、決定は間違っています。begin/endまたはのいずれかから構築可能な範囲オブジェクトを使用したほうがよかったでしょうbegin/length。現在、_n代わりに複数の接尾辞アルゴリズムがあります。

それらを追加すると、パワーが得られず（呼び出し.begin()て.end()自分でコンテナ全体を実行できます）、ライブラリにもう1つ追加する必要があります。などなど

つまり、コンテナ全体のユーザーが1つの追加の関数呼び出しパラメーターを入力するのを防ぐために、追加のテンプレートセットを維持するのは面倒なことではないので、おそらくそこにはないでしょう。

今では、http：//en.wikipedia.org/wiki/C++11#Range-based_for_loopがの優れた代替手段std::for_eachです。明示的な反復子がないことを確認してください。

int a[5] = {1, 2, 3, 4, 5};
for (auto &i: a) { i *= 2; }

（https://stackoverflow.com/a/694534/2097284から着想を得ています。）