Postfix Increment演算子を避ける

パフォーマンス上の理由で（特定の場合に）後置インクリメント演算子を避けるべきだと読みました。

しかし、これはコードの可読性に影響しませんか？私の考えでは：

for(int i = 0; i < 42; i++);
    /* i will never equal 42! */

より良く見える：

for(int i = 0; i < 42; ++i);
    /* i will never equal 42! */

しかし、これはおそらく単なる習慣ではありません。確かに、私は多くの使用を見ていません++i。

この場合、パフォーマンスは可読性を犠牲にするのに悪いですか？または私はただ盲目であり、++iより読みやすいですi++か？

事実：

1. i ++と++ iも同様に読みやすいです。あなたはそれに慣れていないので好きではありませんが、あなたがそれを誤解することは本質的にないので、読み書きするのはもはや仕事ではありません。

2. 少なくともいくつかの場合、後置演算子の効率は低下します。

3. ただし、99.99％の場合、（a）いずれにせよ単純またはプリミティブ型で動作し、大きなオブジェクトをコピーする場合にのみ問題になるため（b）パフォーマンスに影響しないため、問題にはなりません。コードの重要な部分（c）コンパイラが最適化するかどうかわからない場合は、それを行うことができます。

4. したがって、特に（a）他のことを正確に行うのが良い習慣であり、（b）後置詞を使用する予定の青い月に1回という理由だけで、特に接尾辞が必要な場合を除いて接頭辞を使用することをお勧めします間違った方法でやり直してください：常にあなたが意味することを書いているなら、それはあまりありません。パフォーマンスと最適化の間には常にトレードオフがあります。

必要になるまで微最適化するのではなく、常識を使用する必要がありますが、そのためにひどく非効率にならないでください。通常、これは次のことを意味します。最初に、タイムクリティカルでないコード（通常、理由なしに500MBのオブジェクトを値で渡すような基本的な概念エラーを表すもの）でさえ許容できないほど非効率なコード構築を除外します。次に、コードを記述する他のすべての方法のうち、最も明確な方法を選択します。

しかし、ここでは、答えは簡単だと思います：特に接尾辞が必要な場合を除いて接頭辞を書くことは（a）非常にわずかに明確で、（b）非常にわずかに効率的である可能性が高いと思うので、常にデフォルトで書く必要がありますが、忘れても心配しないでください。

半年前、私はあなたと同じように思っていました。i++はもっと自然ですが、それはあなたが慣れているものです。

編集1：私が一般的にこのことを信頼している「より効果的なC ++」のスコット・マイヤーズは、ユーザー定義型でpostfix演算子を使用することを一般的に避けるべきだと言います（postfix increment関数の唯一の正気な実装はオブジェクトのコピー、プレフィックスインクリメント関数を呼び出してインクリメントを実行し、コピーを返しますが、コピー操作は高価になる可能性があります）。

そのため、（a）それが今日当てはまるかどうか、（b）組み込み型にも当てはまるかどうか（c）で「++」を使用すべきかどうかについて、一般的なルールがあるかどうかはわかりません軽量のイテレータークラス以上のもの。しかし、私が上で説明したすべての理由のために、それは重要ではありません。

編集2：これは一般的な慣行を指します。特定のインスタンスで問題があると思われる場合は、プロファイルして確認する必要があります。プロファイリングは簡単で安価で機能します。第一原則から何を最適化する必要があるかを推測するのは難しく、費用がかかり、機能しません。

常に最初にプログラマー用に、次にコンピューター用にコーディングしてください。

パフォーマンスの差がある場合、コンパイラは、コードの上にその専門家の目を投げた後、とあなたはそれを測定することができますと、それは重要-あなたはそれを変更することができます。

GCCは、両方のループに対して同じマシンコードを生成します。

Cコード

int main(int argc, char** argv)
{
    for (int i = 0; i < 42; i++)
            printf("i = %d\n",i);

    for (int i = 0; i < 42; ++i)
        printf("i = %d\n",i);

    return 0;
}

アセンブリコード（私のコメント付き）

    cstring
LC0:
    .ascii "i = %d\12\0"
    .text
.globl _main
_main:
    pushl   %ebp
    movl    %esp, %ebp
    pushl   %ebx
    subl    $36, %esp
    call    L9
"L00000000001$pb":
L9:
    popl    %ebx
    movl    $0, -16(%ebp)  // -16(%ebp) is "i" for the first loop 
    jmp L2
L3:
    movl    -16(%ebp), %eax   // move i for the first loop to the eax register 
    movl    %eax, 4(%esp)     // push i onto the stack
    leal    LC0-"L00000000001$pb"(%ebx), %eax // load the effective address of the format string into the eax register
    movl    %eax, (%esp)      // push the address of the format string onto the stack
    call    L_printf$stub    // call printf
    leal    -16(%ebp), %eax  // make the eax register point to i
    incl    (%eax)           // increment i
L2:
    cmpl    $41, -16(%ebp)  // compare i to the number 41
    jle L3              // jump to L3 if less than or equal to 41
    movl    $0, -12(%ebp)   // -12(%ebp) is "i" for the second loop  
    jmp L5
L6:
    movl    -12(%ebp), %eax   // move i for the second loop to the eax register 
    movl    %eax, 4(%esp)     // push i onto the stack
    leal    LC0-"L00000000001$pb"(%ebx), %eax // load the effective address of the format string into the eax register
    movl    %eax, (%esp)      // push the address of the format string onto the stack
    call    L_printf$stub     // call printf
    leal    -12(%ebp), %eax  // make eax point to i
    incl    (%eax)           // increment i
L5:
    cmpl    $41, -12(%ebp)   // compare i to 41 
    jle L6               // jump to L6 if less than or equal to 41
    movl    $0, %eax
    addl    $36, %esp
    popl    %ebx
    leave
    ret
    .section __IMPORT,__jump_table,symbol_stubs,self_modifying_code+pure_instructions,5
L_printf$stub:
    .indirect_symbol _printf
    hlt ; hlt ; hlt ; hlt ; hlt
    .subsections_via_symbols

パフォーマンスについて心配する必要はありません。97％の時間です。時期尚早の最適化はすべての悪の根源です。

-ドナルドクヌース

これで邪魔にならないので、選択を正気にしましょう。

• ++i：接頭辞インクリメント、現在の値をインクリメントし、結果を生成します
• i++：後置インクリメント、値のコピー、現在の値のインクリメント、コピーの生成

古い値のコピーが必要でない限り、後置インクリメントを使用することは、物事を成し遂げるためのラウンドアラウンドな方法です。

不正確は怠するものであり、常に最も直接的な方法で意図を表現する構成を使用します。将来のメンテナーが元の意図を誤解する可能性は低くなります。

ここでは（本当に）マイナーですが、コードを読んで本当に困惑している場合があります。意図と実際の表現が一致したかどうか、そしてもちろん、数か月後、彼ら（または私）どちらも覚えていませんでした...

だから、あなたにとって正しいかどうかは関係ありません。抱擁のKISS。数か月のうちに、古い慣行を避けることができます。

C ++では、あなたは可能性が関与演算子のオーバーロードがある場合は、あなたがしている書き込みがコードをテンプレートとイテレータが渡されるかもしれないのか分からない。任意のイテレータXの背後にあるロジックは、実質的かつsignificant-両方かもしれ場合は特に、かなりのパフォーマンスの違いを作りますつまり、低速であり、コンパイラによって最適化できません。

しかし、これはCでは当てはまりません。Cの型は些細なタイプにすぎず、パフォーマンスの違いは些細であり、コンパイラは簡単に最適化できます。

ヒント：CまたはC ++でプログラミングし、質問は両方ではなく、どちらか一方に関連しています。

どちらの操作のパフォーマンスも、基盤となるアーキテクチャに大きく依存します。メモリに保存されている値をインクリメントする必要があります。つまり、フォンノイマンのボトルネックが両方の場合の制限要因になります。

++ iの場合、

Fetch i from memory 
Increment i
Store i back to memory
Use i

i ++の場合、

Fetch i from memory
Use i
Increment i
Store i back to memory

++および-演算子は、その起源をPDP-11命令セットにトレースします。PDP-11は、レジスタで自動ポストインクリメントを実行できます。また、レジスタに含まれる有効なアドレスに対して自動プリデクリメントを実行できます。どちらの場合でも、問題の変数が「レジスタ」変数である場合にのみ、コンパイラはこれらのマシンレベルの操作を利用できます。

何かが遅いかどうかを知りたい場合は、テストしてください。BigIntegerまたはそれに相当するものを使用し、両方のイディオムを使用して類似のforループに貼り付け、ループの内部が最適化されていないことを確認し、両方の時間を計ります。

この記事を読んでも、3つの理由からあまり説得力がありません。1つは、コンパイラは使用されないオブジェクトの作成を最適化できる必要があります。2つ目は、i++概念が数値forループのイディオムであるため、実際に影響を受けるケースはに限定されます。3つ目は、純粋に理論的な議論を提供し、それを裏付ける数字はありません。

特に理由＃1に基づいて、私の推測では、あなたが実際にタイミングをとるとき、それらは互いに隣り合っているでしょう。

まず、読みやすさIMOには影響しません。それはあなたが見たことのあるものではありませんが、あなたがそれに慣れるまでにほんの少ししかありません。

第二に、コード内で大量の接尾辞演算子を使用しない限り、多くの違いは見られないでしょう。可能な場合にそれらを使用しない主な理由は、元のvarの値のコピーを、元のvarをまだ使用できる引数の最後まで保持する必要があるということです。これは、アーキテクチャに応じて32ビットまたは64ビットのいずれかです。これは、4または8バイトまたは0.00390625または0.0078125 MBに相当します。非常に高い確率で、非常に長期間保存する必要のある大量のデータを使用しない限り、今日のコンピューターリソースと速度では、接尾辞から接頭辞への切り替えを行っても違いに気付かないでしょう。

編集：私の結論が間違っていることが証明されたので、この残りの部分を忘れてください（++ iとi ++の一部が常に同じことをしているわけではありません...それはまだ真実です）。

また、ケースで同じことをしないことが以前に指摘されました。切り替える場合は、切り替えに注意してください。私はそれを試したことがないので（私はいつもpostfixを使用しました）、確かにわかりませんが、postfixからprefixに変更すると異なる結果になると思います:( 再び間違っている可能性があります...コンパイラに依存します/通訳も）

for (int i=0; i < 10; i++) //the set of i values here will be {0,1,2,3,4,5,6,7,8,9}
for (int i=0; i < 10; ++i) //the set of i values here will be {1,2,3,4,5,6,7,8,9,10}

意味的に++iは、よりも理にかなってi++いると思うので、そうしないのが一般的であることを除いて、最初のものに固執します（Javaのように、i++広く使用されているため使用するべきです）。

パフォーマンスだけではありません。

場合によっては、コピーがまったく意味をなさないため、コピーの実装をまったく避けたい場合があります。また、プレフィックスインクリメントの使用はこれに依存しないため、プレフィックス形式に固執する方が簡単です。

そして、プリミティブ型と複合型に異なる増分を使用しています...それは本当に読みにくいです。

本当に必要でない限り、私は++ iに固執します。ほとんどの場合、これが目的です。i ++が必要になることはほとんどありません。そのような構造を読むときは、常によく考える必要があります。++ iを使用すると、簡単です。1を追加して使用すると、iは同じままです。

だから、私は@martin beckettに心から同意します：あなた自身のためにそれをもっと簡単にしてください。