逆に、コードの流れの中で、インクリメントした後の結果しか使わないのであれば、前置でも後置でもCPUのコストは変わりません。仮にインクリメント演算子の中で70,000サイクルの処理がかかるとしても、インクリメント後の値しか使わないのであれば、前置でも後置でも等しくその負荷が計上されることになります。計測サンプルダラダラとアセンブラコード貼ってる暇があったら実測値をだしてみろよ!投資家は数字でしか動かねーんだよ!というYコンビネーターマインドの方もいるかもしれません。以下のサイトではインクリメントのコストを複数のコンパイラで比較検証されていますので一例として参考にして頂ければと思います。典型的なfor文を前置後置それぞれのインクリメントを使用する形で作成。int/iterator/適当に重めのクラスの三種それぞれを対象。最適化により返り値計算が消えることを考えforの真偽判定でインクリメントの返り値を使用するものも用意。以上をそれぞれ100,000,000回実行をさらに10回繰り返しかかった時間の平均をとる。全計測の結果は元サイトよりご確認下さい。余談ではございますが闇夜のC++のサイト運営に2億くらい出してもいいよというエンジェル投資家の方がいらっしゃいましたら、ご連絡下さい。我々は現実の世界で実際にコードを書くプログラマです。そこには机上の論理以外の様々な要素を考慮する必要があります。結論を出す前に我々が向き合わなければいけない現実的な考慮事項は4つあります。第1に、一時オブジェクトの検証結果ですが、インライン展開が効かない、前置インクリメントにアドバンテージのあるシチュエーションにするには、リンク時最適化の効かないコンパイラ上で、ユーザー定義のインクリメントオペレータ演算子をcpp側に書く必要があります。インクリメント演算子もデクリメント演算子もクラス書くたびに必ず用意してます(しかもヘッダーファイルじゃなくcpp側に!)という人は別として、一般的に最も多く呼び出されるインクリメント演算子は組み込みのint、もしくはSTLのイテレータに対してではないでしょうか。その場合、やはり先程の検証でもあったように、コンパイラの素晴らしい最適化により、前置と後置のコストの違いは限りなく少なくなります。第2に、インクリメント演算によって発生するなんらかのストールを回避するにはインクリメント前の値を使うようなコードを心がける必要があります。インクリメント演算子を式中で使ったり、インクリメント後もインクリメント前の値に対する処理を書くという感じです。可読性の観点からすると、あまり推奨されるようなコードではありません。第3に、ストールのコストは肌で感じづらいという問題があります。処理に直接関係するコストは、例えばアセンブラコードの出力を見れば把握できます。余分なオブジェクトが生成されているな、とか、最適化されているな、とか。あるコードを書いた時にその部分の処理によってCPUにストールが発生しているかというのは極めて把握が難しい問題です。第4に、しかし、それでも、いかんともしがたく、アーキテクチャに引っ張られることがあるという点です。中盤でも触れましたが、一部のアーキテクチャにおいてはストールの発生を抑えなければロクに処理が動かないというケースがあるのも事実です。いうアーキテクチャと向き合わなければならない場合、全く一切選択の余地なく、可読性うんぬん以前に、方針を決めざるをえない場合もあります。CPUのアーキテクチャへの理解と、コンパイラの挙動、そして現実にコードを書く我々、この3つを勘案した上で、実際に前置インクリメントを使うべきか、後置インクリメントを使うべきか、また今の時代そういうことは気にしないべきか、考える必要があります。私は、後置インクリメントを使っている事を指摘した際に「だってゲームエンジン・アーキテクチャに書いてあったからなんとなく」という答えをするプログラマが増えない事だけを願っています。