自明ではない条件文をループの初期化セクションに移動する必要がありますか？

stackoverflow.comのこの質問からこのアイデアを得ました

一般的なパターンは次のとおりです。

final x = 10;//whatever constant value
for(int i = 0; i < Math.floor(Math.sqrt(x)) + 1; i++) {
  //...do something
}

私がやろうとしているのは、条件付きステートメントが複雑なものであり、変わらないということです。

ループの初期化セクションで宣言する方がいいですか？

final x = 10;//whatever constant value
for(int i = 0, j = Math.floor(Math.sqrt(x)) + 1; i < j; i++) {
  //...do something
}

これはもっと明確ですか？

条件式が次のように単純な場合

final x = 10;//whatever constant value
for(int i = 0, j = n*n; i > j; j++) {
  //...do something
}

私がしたいことは次のようなものです：

void doSomeThings() {
    final x = 10;//whatever constant value
    final limit = Math.floor(Math.sqrt(x)) + 1;
    for(int i = 0; i < limit; i++) {
         //...do something
    }
}

正直に言って、ループヘッダーに初期化j（現在limit）を詰め込む唯一の正当な理由は、ループヘッダーのスコープを正しく保つことです。問題にならないようにするために必要なのは、すてきな囲みスコープです。

速くなりたいという欲求は高く評価できますが、本当の正当な理由がなければ読みやすさを犠牲にしないでください。

確かに、コンパイラは最適化でき、複数の変数を初期化することは合法かもしれませんが、ループはそのままではデバッグするのに十分困難です。人間に親切にしてください。これが本当に私たちを遅くすることが判明した場合、それを修正するのに十分それを理解することは素晴らしいことです。

優れたコンパイラーはどちらの方法でも同じコードを生成します。したがって、パフォーマンスが必要な場合は、クリティカルループ内にあり、実際にプロファイルを作成し、違いがある場合にのみ変更を行います。コンパイラーが最適化できない場合でも、関数呼び出しのケースについてのコメントで指摘されているように、ほとんどの場合、パフォーマンスの差はプログラマーが考慮する価値がないほど小さくなります。

しかしながら...

コードは主に人間間のコミュニケーションの媒体であり、両方のオプションが他の人間とうまくコミュニケーションできないことを忘れてはなりません。1つ目は、反復ごとに式を計算する必要があるという印象を与え、2つ目は、初期化セクションにある式がループ内のどこかで更新されることを意味します。

私は実際にループの上に引き出してfinal、コードを読んでいる人にすぐにそれを明確にするようにします。それは変数の範囲を広げるので理想的でもありませんが、とにかくあなたの囲む関数はそれ以上ループを含んではいけません。

@Karl Bielefeldtが彼の答えで言ったように、これは通常問題ではありません。

しかし、それはかつてCとC ++の一般的な問題であり、コードの可読性を低下させることなく問題を回避0しようとするトリックが発生しました。

final x = 10;//whatever constant value
for(int i = Math.floor(Math.sqrt(x)); i >= 0; i--) {
  //...do something
}

現在、すべての反復の条件は、すべての>= 0コンパイラが1つまたは2つのアセンブリ命令にコンパイルするものです。過去数十年間に作成されたすべてのCPUには、次のような基本的なチェックが必要です。x64マシンでクイックチェックを行うと、これが予想通りcmpl $0x0, -0x14(%rbp)（long-int-compare値0 vsレジスタrbpオフセット-14）およびjl 0x100000f59（前の比較が「2nd-arg」の場合、ループに続く命令にジャンプする<1番目の引数」）。

注私が削除したこと+ 1からMath.floor(Math.sqrt(x)) + 1、数学が機能するためには、開始値はである必要がありますint i = «iterationCount» - 1。また、注目に値するのは、イテレータに署名する必要があることです。unsigned int動作せず、おそらくコンパイラ警告が表示されます。

Cベースの言語で約20年間プログラミングした後、forward-index-iterateを行う特別な理由がない限り、逆インデックス反復ループのみを記述します。条件での単純なチェックに加えて、逆反復は、そうでなければ面倒な反復中の配列突然変異を回避します。

Math.sqrt（x）がMymodule.SomeNonPureMethodWithSideEffects（x）に置き換えられると、興味深いものになります。

基本的に私の手口は次のとおりです。何かが常に同じ値を与えると予想される場合、一度だけ評価します。たとえば、List.Countは、ループの操作中にリストが変更されない場合、ループ外のカウントを別の変数に取得します。

これらの「カウント」の一部は、特にデータベースを扱う場合、驚くほど高価になる可能性があります。リストの反復中に変更されるはずのないデータセットで作業している場合でも。

私の意見では、これは言語固有です。たとえば、C ++ 11を使用している場合、条件チェックがconstexpr関数であれば、コンパイラは毎回同じ値を生成することがわかっているため、複数の実行を最適化する可能性が非常に高いと思われます。

ただし、関数呼び出しがライブラリ関数である場合constexpr、コンパイラーはこれを推定できないため、すべての反復でほぼ確実に実行します（インラインであり、したがって純粋であると推定できる場合を除く）。

私はJavaについてあまり知りませんが、それがJITコンパイルされていることを考えると、コンパイラーは実行時に条件をインライン化して最適化するのに十分な情報を持っていると思います。しかし、これは適切なコンパイラー設計に依存し、このループを決定するコンパイラーは最適化の優先事項であり、推測することしかできません。

個人的には、可能であればforループ内に条件を入れる方が少しエレガントだと感じますが、複雑な場合はconstexpror inline関数に書き込むか、関数が純粋で最適化可能であることを示唆する言語に相当するように書きます。これにより、意図が明確になり、巨大な読み取り不能な行を作成することなく、慣用的なループスタイルが維持されます。また、それが独自の機能である場合、条件チェックに名前を付けるため、読者は複雑な場合はチェックせずに、チェックの対象を論理的にすぐに確認できます。