手書きのループよりもアルゴリズムを優先しますか？

次のうち、読みやすいものはどれですか。手書きのループ：

for (std::vector<Foo>::const_iterator it = vec.begin(); it != vec.end(); ++it)
{
    bar.process(*it);
}

またはアルゴリズムの呼び出し：

#include <algorithm>
#include <functional>

std::for_each(vec.begin(), vec.end(),
              std::bind1st(std::mem_fun_ref(&Bar::process), bar));

std::for_eachこのような単純な例を考えると、本当に多くのコードがすでに必要であるため、本当に価値があるのでしょうか。

この問題についてどう思いますか？

ラムダが導入されたのには理由があり、それは標準委員会でさえ2番目の形式が悪いと認識しているためです。C ++ 0xとラムダのサポートが得られるまで、最初の形式を使用します。

常に、意図することを最もよく表すバリアントを使用してください。あれは

の各要素xに対してvec、を実行しますbar.process(x)。

では、例を見てみましょう：

std::for_each(vec.begin(), vec.end(),
              std::bind1st(std::mem_fun_ref(&Bar::process), bar));

私たちもfor_eachそこにいます- イッペ。[begin; end)操作したい範囲があります。

原則として、アルゴリズムははるかに明示的であり、手書きの実装よりも優れていました。しかし、その後 ...バインダー？Memfun？基本的にメンバー関数を取得する方法のC ++内部？私の仕事では、私はそれらを気にしません！また、この冗長で不気味な構文に悩まされたくありません。

今、他の可能性：

for (std::vector<Foo>::const_iterator it = vec.begin(); it != vec.end(); ++it)
{
    bar.process(*it);
}

確かに、これは認識すべき一般的なパターンですが、...イテレータの作成、ループ、インクリメント、逆参照です。これらも、私の仕事を成し遂げるために私が気にしないすべてのものです。

確かに、それは（少なくとも、ループwaayより良い最初のソリューションよりも見える体が柔軟かつきわめて明確である）、それでも、それは本当にないことを素晴らしいです。可能性がなければこれを使用しますが、多分...

より良い方法は？

に戻りfor_eachます。文字通り言うのは素晴らしいことではないかfor_each とも行う必要がある操作に柔軟であること？幸い、C ++ 0xラムダなので、

for_each(v.begin(), v.end(), [&](const Foo& x) { bar.process(x); })

多くの関連する状況に対する抽象的な一般的なソリューションが見つかったので、この特定のケースでは、絶対的な＃1のお気に入りがあることに注意してください。

foreach(const Foo& x, vec) bar.process(x);

本当にそれ以上に明確にすることはできません。ありがたいことに、C ++ 0xは同様の構文が組み込まれています。

これはとても読みにくいので？

for (unsigned int i=0;i<vec.size();i++) {
{
    bar.process(vec[i]);
}

一般に、最初の形式は、どんなバックグラウンドを持っているかに関係なく、forループが何であるかを知っているほとんどの人が読むことができます。

また、一般的に、2番目のものはそれほど読みやすいものではありません。for_eachが何をしているのかを十分に理解するのは簡単ですが、見たことがない場合は、std::bind1st(std::mem_fun_ref理解するのが難しいと想像できます。

実は、C ++ 0xでも、どれだけfor_each愛されるかはわかりません。

for(Foo& foo: vec) { bar.process(foo); }

より読みやすくなります。

アルゴリズム（C ++の場合）で私が嫌いなのは、イテレータを推論し、非常に冗長なステートメントを作成することです。

あなたが関手としてbarを書いたなら、それははるかに簡単です：

// custom functor
class Bar
{    public: void operator()(Foo& value) { /* STUFF */ }
};


std::for_each(vec.begin(), vec.end(), Bar());

ここでコードは非常に読みやすいです。

後者はすっきりとしていてきれいなので、私は後者を好みます。実際には他の多くの言語の一部ですが、C ++ではライブラリの一部です。それは本当に重要ではありません。

今、この問題は実際にはC ++に固有のものではないと私は主張します。

問題は、いくつかのファンクタをさらに別の関数に渡すことは、ループを置き換えることではありません。すぐに頭に浮かぶ訪問者や観察者
などの関数型プログラミングで非常に自然になる特定のパターンを単純化することになっています。 一次関数が不足している言語（Javaがおそらく最良の例です）では、このようなアプローチでは常に、特定のインターフェースを実装する必要があります。

他の言語でよく見られる一般的な使用法は次のとおりです。

someCollection.forEach(someUnaryFunctor);

これの利点は、someCollection実際にどのように実装されているのか、何someUnaryFunctorが行われているのかを知る必要がないことです。あなたが知る必要があるのは、そのforEachメソッドがコレクションのすべての要素を繰り返し、それらを指定された関数に渡すことです。

個人的には、あなたがその立場にいる場合、反復したいデータ構造に関するすべての情報と、すべての反復ステップで何をしたいかについてのすべての情報を得るために、特に言語において、機能的アプローチは物事を複雑にしています。これは一見かなり退屈です。

また、forループにはない、一定のコストで呼び出される呼び出しが多数あるため、関数型のアプローチは低速になることにも注意してください。

ここでの問題はfor_each、それが実際にはアルゴリズムではなく、手書きのループを書くこととは異なる（そして通常は劣る方法）だと思います。この観点から、これは最も使用頻度の低い標準アルゴリズムである必要があり、はい、おそらくforループを使用することもできます。ただし、より具体的な用途に合わせて調整されたいくつかの標準アルゴリズムがあるため、タイトルのアドバイスは依然として有効です。

必要なことをより厳密に実行するアルゴリズムがある場合は、手書きのループよりもアルゴリズムを優先する必要があります。ここで明らかな例がでソートされているsortか、stable_sortまたはで検索lower_bound、upper_boundまたはequal_range、それらのほとんどは、彼らが手コード化されたループの上使用することが好ましいされたいくつかの状況があります。

この小さなコードスニペットでは、どちらも同じように読みやすくなっています。一般に、手動ループはエラーが発生しやすく、アルゴリズムの使用を好みますが、実際には具体的な状況に依存します。