C ++には「未定義の動作」（UB）があり、C＃やJavaなどの他の言語にはないのはなぜですか？

このStack Overflowの投稿には、C / C ++言語仕様が「未定義の動作」であると宣言している状況のかなり包括的なリストがリストされています。ただし、C＃やJavaなどの他の現代言語に「未定義の動作」という概念がない理由を理解したいと思います。つまり、コンパイラの設計者は、考えられるすべてのシナリオ（C＃およびJava）を制御できるかどうか（CおよびC ++）を制御できますか？

未定義の動作は、振り返ってみて非常に悪い考えとして認識されたものの1つです。

最初のコンパイラーは素晴らしい成果であり、機械語またはアセンブリー言語プログラミングの代替案に対する改善を喜んで歓迎しました。それに関する問題はよく知られており、これらの既知の問題を解決するために高級言語が特に発明されました。（当時の熱意は非常に大きかったので、HLLは「プログラミングの終わり」と呼ばれることもありました。これからは、私たちが望んでいることをささいに書き留めて、コンパイラがすべての実際の作業を行うようになります。）

新しいアプローチに伴う新しい問題に気付いたのは、後になってからです。コードが実行される実際のマシンから離れているということは、予期したとおりに動作しない可能性が静かにあることを意味します。たとえば、変数を割り当てると、通常、初期値は未定義のままになります。値を保持したくない場合は変数を割り当てないため、これは問題とは見なされませんでしたか？確かに、プロのプログラマーが初期値を割り当てることを忘れないことを期待することはあまりありませんでしたか？

より強力なプログラミングシステムで可能になった、より大きなコードベースとより複雑な構造により、多くのプログラマーがそのような見落としを時々犯すことが判明し、結果として生じる未定義の動作が大きな問題になりました。今日でも、小さなものから恐ろしいものまでのセキュリティリークの大部分は、何らかの形での未定義の動作の結果です。（その理由は、通常、未定義の動作は実際にはコンピューティングの次の下位レベルのものによって非常に定義されており、そのレベルを理解している攻撃者はプログラムを作成するためにその小刻みの部屋を使用して、意図しないものだけでなく、まさに物事を行うことができるからです彼らは意図している。）

これを認識してから、未定義の動作を高レベル言語から排除する一般的な動きがあり、Javaはこれについて特に徹底的でした（とにかく独自に設計された仮想マシンで実行するように設計されているため、比較的簡単でした）。Cのような古い言語は、膨大な量の既存のコードとの互換性を失わずに、そのように簡単に改造することはできません。

編集：指摘したように、効率性は別の理由です。未定義の動作とは、コンパイラの作成者がターゲットアーキテクチャを活用するための多くの余裕があり、各実装が各機能の可能な限り高速な実装で逃げることを意味します。これは、プログラマの給料がソフトウェア開発のボトルネックであることが多い今日よりも昨日の電力不足のマシンでより重要でした。

基本的に、Javaおよび同様の言語の設計者は、言語で未定義の動作を望んでいないためです。これはトレードオフでした。未定義の動作を許可するとパフォーマンスが向上する可能性がありますが、言語設計者は安全性と予測可能性を優先しました。

たとえば、Cで配列を割り当てた場合、データは未定義です。Javaでは、すべてのバイトを0（または他の指定された値）に初期化する必要があります。つまり、ランタイムは配列を渡さなければならず（O（n）操作）、Cは即座に割り当てを実行できます。そのため、このような操作ではCは常に高速になります。

読む前に、配列を使用するコードが配列にデータを取り込む場合、これは基本的にJavaにとって無駄な努力です。ただし、コードが最初に読み取られる場合、Javaでは予測可能な結果が得られますが、Cでは予測できない結果が得られます。

未定義の動作により、コンパイラに特定の境界または他の条件で奇妙または予期しない（または通常の）処理を行う自由度を与えることにより、大幅な最適化が可能になります。

http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.htmlを参照してください

初期化されていない変数の使用：これは一般にCプログラムの問題の原因として知られ、これらをキャッチする多くのツールがあります：コンパイラの警告から静的および動的アナライザーまで。これにより、（Javaのように）すべての変数がスコープに入ったときにゼロで初期化する必要がなくなるため、パフォーマンスが向上します。ほとんどのスカラー変数の場合、これはオーバーヘッドをほとんど引き起こしませんが、スタック配列とmallocされたメモリはストレージのmemsetを被り、特にストレージは通常完全に上書きされるため、非常にコストがかかります。

符号付き整数オーバーフロー：「int」型の演算が（たとえば）オーバーフローした場合、結果は未定義です。たとえば、「INT_MAX + 1」がINT_MINであるとは限りません。この動作により、一部のコードにとって重要な特定のクラスの最適化が可能になります。たとえば、INT_MAX + 1が未定義であることを知っていると、「X + 1> X」を「true」に最適化できます。乗算のオーバーフローを「できない」ことを知ると（そうすることは未定義になるため）、「X * 2/2」から「X」への最適化が可能になります。これらは些細なことのように思えるかもしれませんが、これらの種類のものは一般にインライン化とマクロ展開によって公開されます。これが許可するより重要な最適化は、次のような「<=」ループ用です。

for (i = 0; i <= N; ++i) { ... }

このループでは、コンパイラーは、オーバーフロー時に「i」が未定義の場合、ループが正確にN + 1回繰り返されると想定できます。これにより、広範なループ最適化を開始できます。オーバーフローでラップアラウンドすると、コンパイラーはループが無限である可能性があると仮定する必要があります（NがINT_MAXの場合に発生します）-これらの重要なループ最適化を無効にします。多くのコードが誘導変数として「int」を使用するため、これは特に64ビットプラットフォームに影響します。

Cの初期には、多くの混乱がありました。コンパイラが異なれば、言語の扱いも異なります。言語の仕様を作成することに関心がある場合、その仕様は、プログラマーがコンパイラーに依存していたCとかなり後方互換性が必要です。ただし、これらの詳細の一部は移植性がなく、一般的には意味がありません。たとえば、特定のエンディアンやデータレイアウトを想定しています。したがって、C標準では、未定義の動作または実装指定の動作として多くの詳細が予約されており、コンパイラの作成者には多くの柔軟性が残されています。C ++はCに基づいて構築されており、未定義の動作も備えています。

Javaは、C ++よりもはるかに安全でシンプルな言語になろうとしました。Javaは、完全な仮想マシンに関して言語のセマンティクスを定義します。これにより、未定義の動作のためのスペースがほとんどなくなりますが、一方で、Java実装では困難な要件を作成します（たとえば、参照の割り当てはアトミックである必要がある、または整数の動作方法）。Javaが潜在的に安全でない操作をサポートする場合、それらは通常、実行時に仮想マシンによってチェックされます（たとえば、一部のキャスト）。

JVMおよび.NET言語は簡単です。

1. ハードウェアを直接操作できる必要はありません。
2. それらは、最新のデスクトップおよびサーバーシステム、または合理的に同様のデバイス、または少なくともそれらのために設計されたデバイスでのみ動作する必要があります。
3. すべてのメモリにガベージコレクションを強制し、初期化を強制して、ポインタの安全性を確保できます。
4. それらは、単一の決定的な実装も提供した単一のアクターによって指定されました。
5. 彼らはパフォーマンスよりも安全を選択するようになります。

ただし、選択には良い点があります。

1. システムプログラミングはまったく異なるものであり、代わりにアプリケーションプログラミングの妥協のない最適化が妥当です。
2. 確かに、常にエキゾチックなハードウェアは少なくなっていますが、小さな組み込みシステムはここにあります。
3. GCは、代替不可能なリソースには不向きであり、パフォーマンスを向上させるためにはるかに多くのスペースを使用します。また、ほとんどの（ほとんどすべてではない）強制的な初期化は、最適化して削除できます。
4. より多くの競争には利点がありますが、委員会は妥協を意味します。
5. これらのすべての境界チェックは、ほとんどが最適化されて離れていても、合計されます。最適化はまだ禁止されていますが、ほとんどの場合、ヌルポインターチェックは、仮想アドレス空間のおかげでオーバーヘッドをゼロにするためにアクセスをトラップすることで実行できます。

エスケープハッチが提供される場合、それらは完全な未定義の振る舞いを呼び戻します。しかし、少なくともそれらは通常、ごく少数の非常に短いストレッチでのみ使用されるため、手動で確認する方が簡単です。

JavaとC＃の特徴は、少なくとも開発の初期段階にある主要ベンダーです。（それぞれSunとMicrosoft）。CとC ++は異なります。早くから複数の競合する実装がありました。Cは、特にエキゾチックなハードウェアプラットフォームでも実行されました。その結果、実装間にばらつきがありました。CとC ++を標準化したISO委員会は、大きな共通点に同意することができましたが、実装が異なる端では、標準が実装の余地を残していました。

これは、1つの動作を選択すると、別の選択に偏ったハードウェアアーキテクチャではコストがかかる可能性があるためです-エンディアンネスは明らかな選択です。

本当の理由は、一方ではCとC ++、もう一方ではJavaとC＃（ほんの2、3の例のみ）の意図の根本的な違いに帰着します。歴史的な理由から、ここでの議論の多くはC ++ではなくCについて述べていますが、（おそらくご存知のように）C ++はCのかなり直接的な子孫なので、Cについて言うことはC ++にも等しく当てはまります。

UNIXの大部分は忘れられていますが（その存在は時には否定されることもあります）、UNIXの最初のバージョンはアセンブリ言語で書かれていました。Cの当初の目的の大部分は（もしそうでないとしても）、UNIXをアセンブリ言語から高レベル言語に移植することでした。意図の一部は、可能な限り多くのオペレーティングシステムを高レベルの言語で記述すること、またはアセンブリ言語で書かなければならない量を最小限に抑えるために他の方向からそれを調べることでした。

それを実現するために、Cは、アセンブリ言語とほぼ同じレベルのハードウェアへのアクセスを提供する必要がありました。PDP-11は（一例として）I / Oレジスタを特定のアドレスにマップしました。たとえば、1つのメモリ位置を読み取って、システムコンソールでキーが押されたかどうかを確認します。読み取りを待機しているデータがあるときに、その場所に1ビットが設定されました。次に、指定された別の場所から1バイトを読み取り、押されたキーのASCIIコードを取得します。

同様に、一部のデータを印刷する場合は、指定した別の場所を確認し、出力デバイスの準備ができたら、指定した別の場所にデータを書き込みます。

このようなデバイスのドライバーの作成をサポートするために、Cでは、整数型を使用して任意の場所を指定し、ポインターに変換して、その場所をメモリ内で読み書きできます。

もちろん、これにはかなり深刻な問題があります。地球上のすべてのマシンのメモリが1970年代初期のPDP-11と同じようにレイアウトされているわけではありません。そのため、その整数を受け取ってポインターに変換し、そのポインターを介して読み取りまたは書き込みを行うと、取得しようとしているものについて誰も合理的な保証を提供できません。わかりやすい例として、読み取りと書き込みはハードウェア内の別々のレジスタにマッピングされる可能性があるため、何かを書き込んでからそれを読み直そうとすると、（通常のメモリとは対照的に）読んだ内容が書き込んだ内容と一致しない場合があります。

残る可能性がいくつかあります。

1. 考えられるすべてのハードウェアへのインターフェースを定義します。何らかの方法でハードウェアとやり取りするために、読み取りまたは書き込みが必要なすべての場所の絶対アドレスを指定します。
2. そのレベルのアクセスを禁止し、そのようなことをしたい人はだれでもアセンブリ言語を使用する必要があることを宣言します。
3. 人々がそれを行うことを許可しますが、ターゲットとするハードウェアのマニュアルを読んで（たとえば）、使用しているハードウェアに合うようにコードを書くことは彼らに任せます。

これらのうち、1は十分に馬鹿げているように思われるので、さらに議論する価値はほとんどありません。2は基本的に言語の基本的な意図を捨てています。これにより、3番目のオプションは、本質的に合理的に検討できる唯一のオプションとなります。

かなり頻繁に発生する別のポイントは、整数型のサイズです。Cは、intアーキテクチャによって提案された自然なサイズであるはずの「位置」を取ります。したがって、32ビットVAXをプログラミングする場合、intおそらく32ビットである必要がありますが、36ビットUnivacをプログラミングする場合、intおそらく36ビット（など）である必要があります。サイズが8ビットの倍数であることが保証されている型のみを使用して36ビットコンピューターのオペレーティングシステムを記述することは、おそらく合理的ではありません（不可能な場合もあります）。たぶん私は表面的なだけかもしれませんが、36ビットマシン用のOSを書いているなら、おそらく36ビットタイプをサポートする言語を使いたいと思うようです。

言語の観点から、これはさらに未定義の動作につながります。32ビットに収まる最大値を取得した場合、1を追加するとどうなりますか？通常の32ビットハードウェアでは、ロールオーバー（または、何らかのハードウェア障害が発生する可能性があります）一方、36ビットのハードウェアで実行されている場合は、追加するだけです。言語がオペレーティングシステムの記述をサポートする場合、どちらの動作も保証できません。型のサイズとオーバーフローの動作の両方を異なるように許可する必要があります。

JavaとC＃はそれらすべてを無視できます。オペレーティングシステムの記述をサポートすることを目的としていません。それらを使用すると、いくつかの選択肢があります。1つは、ハードウェアが要求するものをサポートするようにすることです。8、16、32、64ビットのタイプを要求するため、それらのサイズをサポートするハードウェアを構築するだけです。他の明らかな可能性は、基礎となるハードウェアが何を望んでいるかに関係なく、言語が彼らが望む環境を提供する他のソフトウェアの上でのみ動作することです。

ほとんどの場合、これは実際にはどちらかまたは両方の選択肢ではありません。むしろ、多くの実装は両方を少し実行します。通常、オペレーティングシステムで実行されているJVMでJavaを実行します。多くの場合、OSはCで、JVMはC ++で記述されています。JVMがARM CPUで実行されている場合、CPUにARMのJazelle拡張機能が含まれており、ハードウェアをJavaのニーズにより近づけるため、ソフトウェアで実行する必要が少なくなり、Javaコードの実行速度が速くなりますとにかくゆっくり）。

概要

CとC ++には未定義の動作があります。これは、誰もが意図したことを実行できる許容可能な代替手段を定義していないためです。C＃とJavaは別のアプローチを取りますが、そのアプローチはCとC ++の目標に（もしあれば）不十分に適合します。特に、どちらも、arbitrarily意的に選択されたほとんどのハードウェア上でシステムソフトウェア（オペレーティングシステムなど）を作成するための合理的な方法を提供していないようです。どちらも通常、既存のシステムソフトウェア（通常はCまたはC ++で記述されている）が提供する機能に依存してジョブを実行します。

C規格の作成者は、読者が自明であると思ったものを認識することを期待し、公開された根拠でほのめかしましたが、率直に言ってはいません。なぜなら、顧客は委員会よりも自分のニーズをよく知っている必要があるからです。特定の種類のプラットフォームのコンパイラが特定の方法でコンストラクトを処理することが予想されることが明らかな場合、そのコンストラクトが未定義の動作を呼び出すとスタンダードが言うかどうかは誰も気にする必要はありません。規格に適合したコンパイラがコードの一部を有効に処理することを義務付けていないことは、プログラマがそうでないコンパイラを喜んで購入する必要があることを意味するものではありません。

言語設計に対するこのアプローチは、コンパイラの作成者が製品を有料の顧客に販売する必要がある世界では非常にうまく機能します。コンパイラの作者が市場の影響から孤立している世界では、完全にばらばらになります。1990年代に人気を博した言語を操作した方法で言語を操作するための適切な市場条件が存在することは疑わしく、健全な言語設計者がそのような市場条件に依存することをさらに疑います。

C ++とcの両方に記述的な標準があります（とにかくISOバージョン）。

言語がどのように機能するかを説明し、言語が何であるかについて単一の参照を提供するためにのみ存在します。通常、コンパイラベンダーとライブラリライターが道をリードし、いくつかの提案が主要なISO標準に含まれます。

JavaとC＃（またはVisual C＃、私があなたが言うことを意味する）には規範的な標準があります。彼らは、事前に明確に言語に何が含まれているか、それがどのように機能するか、そして許可された行動とみなされるものを教えてくれます。

それよりも重要なことは、Javaには実際にOpen-JDKに「参照実装」があるということです。（RoslynはVisual C＃の参照実装と見なされますが、そのソースは見つかりませんでした。）

Javaの場合、標準にあいまいさがあり、Open-JDKは特定の方法でそれを行います。Open-JDKが行う方法は標準です。

未定義の動作により、コンパイラはさまざまな設計者に対して非常に効率的なコードを生成できます。エリックの答えは最適化に言及していますが、それはそれを超えています。

たとえば、符号付きオーバーフローはCの未定義の動作です。実際には、コンパイラはCPUが実行する単純な符号付き加算オペコードを生成することが期待されており、その動作は特定のCPUが実行するものです。

これにより、Cはほとんどのアーキテクチャで非常に優れたパフォーマンスを発揮し、非常にコンパクトなコードを生成できました。符号付き整数が特定の方法でオーバーフローする必要があると規格が指定している場合、異なる動作をするCPUは、単純な符号付き加算のために、より多くのコード生成を必要とします。

これが、Cの未定義の動作の多くの理由でintあり、サイズのようなものがシステム間で異なる理由です。Intは、アーキテクチャに依存し、一般に、より大きい最大で最も効率的なデータ型として選択されますchar。

Cが新しい頃、これらの考慮事項は重要でした。コンピューターはそれほど強力ではなく、多くの場合、処理速度とメモリが制限されていました。Cはパフォーマンスが本当に重要な場所で使用され、開発者は、これらの未定義の動作が特定のシステムで実際にどのようなものになるかを知るのに十分なほどコンピューターが機能する方法を理解することが期待されていました。

JavaやC＃などの最近の言語は、未処理のパフォーマンスよりも未定義の動作を排除することを好みました。

ある意味では、Javaにもそれがあります。Arrays.sortに誤ったコンパレータを指定したとします。それの検出の例外をスローすることができます。それ以外の場合、特定のことを保証しない何らかの方法で配列をソートします。

同様に、複数のスレッドの変数を変更すると、結果も予測できなくなります。

C ++は、さらに定義されていない状況（または、むしろJavaがより多くの操作を定義することを決定した）を作り、その名前を付けるためにさらに進んでいます。