x = x ++が未定義なのはなぜですか？

xシーケンスポイント間で2回変更されるため、未定義です。標準では、定義されていないため、定義されていません。
それだけ知っています。

しかし、なぜ？

私の理解では、これを禁止することで、コンパイラーの最適化が向上します。Cが発明されたとき、これは理にかなっていたかもしれませんが、今は弱い議論のように思えます。
今日Cを再発明する場合、この方法でそれを行うのでしょうか、それとももっと良くすることができますか？
または、より深い問題があり、そのような式に一貫したルールを定義するのが難しくなるので、それらを禁止するのが最善ですか？

したがって、今日Cを再発明するとします。のような式の単純なルールを提案したいのx=x++ですが、これは既存のルールよりもうまく機能しているように思えます。
提案されたルールを既存のルールと比較したり、他の提案について意見を聞きたいと思います。

推奨ルール：

1. シーケンスポイント間では、評価の順序は指定されていません。
   
2. 副作用はすぐに起こります。
   

関連する未定義の動作はありません。式はこの値またはそれを評価しますが、確かにハードディスクをフォーマットしません（奇妙なことに、x=x++ハードディスクをフォーマットする実装を見たことはありません）。

式の例

1. x=x++-明確に定義され、変更されませんx。
   最初に、x（x++評価されるとすぐに）インクリメントされ、次に古い値がに保存されxます。

2. x++ + ++x-2 x回インクリメントし、評価され2*x+2ます。
   どちらかの側が最初に評価されますが、結果はx + (x+2)（左側が最初）または(x+1) + (x+1)（右側が最初）です。

3. x = x + (x=3)-指定なし、またはにx設定。 右側が最初に評価される場合、それはです。最初に評価される可能性もあるため、です。どちらの場合でも、評価は評価されるとすぐに行われるため、保存されている値は他の割り当てによって上書きされます。x+36
x+3x=33+3x=3x=3

4. x+=(x=3)-明確に定義され、x6 に設定されます。
   これは、上記の表現の単なる省略形であると言えます。
   ただし、2つの部分（読み取り、評価、追加、新しい値の保存）ではなく、の+=後x=3に実行する必要があります。xx=3

利点は何ですか？

いくつかのコメントはこの良い点を提起しました。
私は確かに、そのような表現x=x++は通常のコードで使用されるべきだとは思いません。
実は、私ははるかに厳しいものよりだ-私はのための唯一の良い使い方を考えるx++ようでx++;一人で。

ただし、言語のルールはできるだけシンプルでなければなりません。それ以外の場合、プログラマーはそれらを理解しません。シーケンスポイント間で変数を2回変更することを禁止する規則は、ほとんどのプログラマーが理解していない規則です。

非常に基本的なルールは次のとおり
です。Aが有効で、Bが有効であり、それらが有効な方法で結合されている場合、結果は有効です。
xは有効なL値でx++あり、有効な式であり=、L値と式を組み合わせる有効な方法x=x++です。
C標準はここで例外を作成し、この例外はルールを複雑にします。stackoverflow.comを検索して、この例外がユーザーをどれほど混乱させるかを確認できます。
だから私は言う-この混乱を取り除く。

===回答の要約===

1. どうしてですか？
   上記のセクションで説明しようとしました-Cルールをシンプルにしたいのです。

2. 最適化の可能性：
   これはコンパイラーからある程度の自由を奪いますが、それが重要であると私に納得させるものは見ませんでした。
   ほとんどの最適化は引き続き実行できます。たとえばa=3;b=5;、標準で順序が指定されていても、並べ替えることができます。などの式もa=b[i++]同様に最適化できます。
   

3. 既存の標準を変更することはできません。
   認められない、できない。規格やコンパイラを実際に変更できるとは思っていませんでした。物事が違ったやり方でできたのかどうかを考えたかっただけです。
   

たぶん、なぜそれを定義すべきなのかという質問に答えるべきでしょうか？そのような式に追加の副作用を許可することで、プログラミングスタイル、可読性、保守性、またはパフォーマンスに利点はありますか？は

y = x++ + ++x;

より読みやすい

y = 2*x + 2;
x += 2;

このような変更は非常に基本的なものであり、既存のコードベースを壊すものです。

この未定義の動作を行うことで最適化が改善されるという議論は、今日では弱くありません。実際、Cが新しくなったときよりも今日はずっと強いです。

Cが新しい場合、これを活用して最適化を改善できるマシンは、ほとんどが理論モデルでした。コンパイラは、他の命令と並行して実行できる/実行すべき命令についてコンパイラがCPUに指示するCPUを構築する可能性について人々から話していました。彼らは、これに未定義の動作を持たせることは、そのようなCPUで実際に存在した場合、命令の「増分」部分を残りの命令ストリームと並行して実行するようにスケジュールできることを指摘しました。彼らは理論については正しかったが、当時はこの可能性を実際に活用できるハードウェアの方法はほとんどなかった。

それはもはや単なる理論ではありません。現在、実稼働環境で広く使用されているハードウェア（Itanium、VLIW DSPなど）が実際に活用されています。彼らは本当にやるコンパイラが指定されていることは、命令X、YおよびZはすべて並列に実行することができ、命令ストリームを生成することができます。これはもはや理論的なモデルではなく、実際に使用して実際の作業を行う実際のハードウェアです。

IMO、この定義された動作を行うことは、問題に対する可能な限り最悪の「解決策」に近いものです。明らかに、このような式は使用しないでください。大部分のコードにとって、理想的な動作は、コンパイラがそのような式を完全に拒否することです。当時、Cコンパイラは、それを確実に検出するために必要なフロー分析を行いませんでした。元のC標準の時点でさえ、まだ一般的ではありませんでした。

今日のコミュニティに受け入れられるかどうかはわかりません。多くのコンパイラーがそのようなフロー分析を実行できますが、通常は最適化を要求したときにのみ実行します。ほとんどのプログラマーは、（正気で）最初に書かないコードを拒否できるようにするためだけに、「デバッグ」ビルドの速度を落とすというアイデアを望んでいません。

Cがやったことは、準合理的な次善の選択です。人々にそうしないように伝え、コンパイラがコードを拒否することを許可します（必須ではありません）。これにより、それを使用したことがない人のコンパイルが（さらに）遅くなることはありませんが、誰かがそのようなコードを拒否するコンパイラを書くことができます（そして/または人々がそれを拒否するフラグを使用することを選択できます）彼らが合うと思うかどうか）。

少なくともIMOで、この定義された動作を行うことは、最悪の決定を下すことです（少なくともそれに近い）。VLIWスタイルのハードウェアでは、増分演算子を乱用する安っぽいコードのためだけに、増分演算子を適切に使用するために低速のコードを生成するか、対処していないことを証明するために常に広範なフロー分析が必要になります安っぽいコードなので、本当に必要な場合にのみ低速（シリアル化）コードを生成できます。

結論：この問題を解決したい場合は、反対方向に考えるべきです。そのようなコードが何をするのかを定義する代わりに、そのような式がまったく許可されないように言語を定義する必要があります（そして、ほとんどのプログラマーはおそらく、その要件を強制するよりも高速なコンパイルを選択するという事実と共存します）。

C＃コンパイラチームのプリンシパルデザイナーであるEric Lippert は、言語仕様レベルで機能を未定義にすることを選択する際の考慮事項に関する記事をブログに投稿しました。C＃は明らかに言語であり、その言語設計にはさまざまな要素が含まれていますが、それでもC＃は重要です。

特に、既存の実装を持ち、委員会の代表者を持つ言語用の既存のコンパイラを持つ問題を指摘しています。ここに当てはまるかどうかはわかりませんが、ほとんどのCおよびC ++関連の仕様の議論に関連する傾向があります。

また、あなたが言ったように、コンパイラ最適化のパフォーマンスの可能性も注目に値します。最近のCPUのパフォーマンスは、Cが若い頃よりも桁違いに大きいことは事実ですが、最近行われた大量のCプログラミングは、潜在的なパフォーマンスの向上と（仮想的な未来）CPU命令の最適化とマルチコア処理の最適化は、副作用とシーケンスポイントを処理するための一連の規則が過度に制限されているため、除外するのはばかげています。

最初に、未定義の動作の定義を見てみましょう。

3.4.3

1 この国際規格が要件を課していない、移植性のないまたは誤ったプログラム構造または誤ったデータを使用した場合の未定義の動作
動作

2環境に固有の文書化された方法（診断メッセージの発行ありまたはなし）、翻訳または実行の終了（診断メッセージの発行あり）。

3例未定義の動作の例は、整数オーバーフローの動作です。

つまり、「未定義の動作」とは、コンパイラが状況に応じて自由に処理できることを意味し、そのようなアクションはすべて「正しい」と見なされます。

議論中の問題の根本は次の節です。

6.5式

...
3演算子とオペランドのグループ化は構文によって示されます。 ^74） 特異的に（後編ファンクションコールのためされている場合を除き()、&&、||、?:）、およびコンマ演算子、部分式の評価の順序及び副作用が起こる順序は、両方unspeciのfi EDあります。

強調が追加されました。

次のような式が与えられた場合

x = a++ * --b / (c + ++d);

部分式はa++、--b、c、と++d評価することができる任意の順序で。さらに、、、およびの副作用はa++、次のシーケンスポイントの前の任意のポイントに適用できます（IOWは、以前に評価された場合でも、評価される前に更新さ れることは保証されません）。他の人が言ったように、この動作の理論的根拠は、実装に最適な方法で操作を並べ替える自由を与えることです。 --b++da++--ba--b

ただし、このため、次のような式

x = x++
y = i++ * i++
a[i] = i++
*p++ = -*p    // this one bit me just yesterday

などにより、実装ごとに異なる結果が得られます（または、最適化設定が異なる同じ実装、または周囲のコードなどに基づいて）。

動作は未定義のままであるため、コンパイラは、それが何であれ「正しいことをする」義務を負いません。上記のケースはキャッチするのに十分簡単ですが、コンパイル時にキャッチするのが困難または不可能になるケースが非常に多くあります。

明らかに、評価の順序と副作用が適用される順序が厳密に定義されるように言語を設計できます。JavaとC＃の両方は、CとC ++の定義が引き起こす問題を回避するために、JavaとC＃の両方が厳密に定義されます。

では、なぜ標準の3つの改訂後にこの変更がCに行われなかったのでしょうか？まず第一に、40年分のレガシーCコードがあり、そのような変更がそのコードを壊さないという保証はありません。このような変更により、既存のすべてのコンパイラがすぐに不適合になるため、コンパイラの作成者に少し負担がかかります。誰もが大幅に書き直さなければなりません。また、高速で最新のCPUでも、評価の順序を微調整することで実際のパフォーマンスの向上を実現できます。

最初に、定義されていないのはx = x ++だけではないことを理解する必要があります。x = x ++については誰も気にしません。何を定義しても意味がありません。定義されていないものは、「aとbが同じであるa = b ++」のようなものです。つまり、

void f(int *a, int *b) {
    *a = (*b)++;
}
int i;
f(&i, &i);

プロセッサアーキテクチャ（およびこれが例よりも複雑な関数である場合は周囲のステートメント）で最も効率的なものに応じて、関数の実装方法はいくつかあります。たとえば、2つの明らかなもの：

load r1 = *b
copy r2 = r1
increment r1
store *b = r1
store *a = r2

または

load r1 = *b
store *a = r1
increment r1
store *b = r1

上記の最初のもの、より多くの命令とより多くのレジスタを使用するものは、aとbが異なることが証明できないすべての場合に使用する必要があるものであることに注意してください。

レガシー

Cが今日再発明されるという仮定は成り立ちません。作成され、毎日使用されているCコードの行が非常に多いため、プレイの途中でゲームのルールを変更するのは間違っています。

もちろん、ルールを使用してC + =などの新しい言語を発明できます。しかし、それはCではありません。

何かが定義されていると宣言しても、既存のコンパイラは変更されず、定義が尊重されます。これは、多くの場所で明示的または暗黙的に信頼されている可能性のある仮定の場合に特に当てはまります。

仮定の主な問題はx = x++;（コンパイラーが簡単にチェックでき、警告する必要がある）ではなく、コンパイラーが（C99で）簡単に知ることができない*p1 = (*p2)++（p1[i] = p2[j]++;p1とp2が関数のパラメーターである場合）と同等ですシーケンスポイント間でp1！= p2を想定する可能性を広げるために追加されたため、最適化の可能性が重要であると見なされました）。p1 == p2restrict

場合によっては、この種のコードは新しいC ++ 11標準で定義されています。