前章で、コンパイラがソースコードを機械語に変換することを学びました。

その出力はオブジェクトファイル。

機械語が入っている。しかし、まだ実行はできない。

アドレスが埋まっていない部品の状態。

部品があるだけでは、プログラムは動きません。

部品を結合し、足りないアドレスを埋め、メモリに配置し、CPUに実行を開始させる。

今日は、オブジェクトファイルが動くプログラムになるまでの過程を見ます。

第125章へようこそ。

第124章で、Rustがコンパイル時に保証できないものを実行時に検査することを語りました。

その中で、パニックを「回復すべきでないバグの検出」と位置づけました。

今日のテーマは「パニック」です。

パニックとは何か。

なぜ存在するのか。

何が起きるのか。

そしてResultとの境界はどこにあるのか。

第14章で、コンパイラが高級言語を機械語に変換することを学びました。

第19章で、プログラムがシステムコールを通じてOSに頼みごとをすることを学びました。

では、ソースコードが機械語になるまでに、何が起きているのか。

人間の言葉で書かれたプログラムを、CPUが実行できる0と1の列に変える。

この変換は、一瞬で終わるような単純なものではありません。

今日は、コンパイラの中で何が起きているのかを見ていきます。

第124章へようこそ。

第123章で、安全の境界を語りました。

Rustはunsafeというキーワードと型システムで、安全な領域と安全でない領域を分離する。

安全な領域では、コンパイラがメモリ安全とデータ競合の不在を保証する。

今日のテーマは「実行時の検査」です。コンパイラが手放したものを見ていきます。

Rustはコンパイル時に多くのことを保証する言語です。

所有権。借用。ライフタイム。型の整合性。スレッド安全性。

しかし、すべてをコンパイル時に保証しているわけではありません。

配列の範囲外アクセスは、実行時に検査される。

整数のゼロ除算は、実行時に検出される。

RefCellの借用規則違反は、実行時に発覚する。

Rustがあえてコンパイル時に保証しなかったものがある。

実行時の検査に委ねたものがある。

なぜ、すべてをコンパイル時に解決しなかったのか。

その判断には、明確な理由があります。

前章で、OSがプロセスを管理していることを学びました。

メモリ空間の用意、CPUの割り当て、プロセス間の隔離。

OSは多くのことをやっています。

では、プログラムはOSにどうやって頼みごとをするのか。

「ファイルを開きたい」

「メモリをもっと欲しい」

「データをネットワークに送りたい」

これらの要求を伝える仕組みが「システムコール」です。

第123章へようこそ。

第122章で、式指向を語りました。

すべてがを返し、データの流れがコードの表面に見える。

今日のテーマは「安全の境界」です。

Rustは安全な言語だと言われます。

メモリ安全を保証し、データ競合を防ぐ。

しかし、Rustのすべてのコードが安全なわけではありません。

ハードウェアを直接操作する場面がある。

他の言語で書かれたコードを呼び出す場面がある。

コンパイラが検証できない不変条件を、人間が保証しなければならない場面がある。

Rustはこれらの場面を禁止するのではなく、「安全な領域」と「安全でない領域」の境界を明確に引きます。

その境界は、暗黙の規約ではない。

unsafeというキーワードと、型システムの構造によって、コードに刻まれている。

前章で、プログラムのメモリ空間がテキスト、データ、スタック、ヒープに

分かれていることを学びました。

でも、この「メモリ空間」は、誰が用意しているのでしょうか。

プログラムが起動してから終了するまで、誰が面倒を見ているのか。

答えは「OS」です。

オペレーティングシステム。

そしてOSがプログラムを管理する単位が「プロセス」です。

プロセスとは何か。

なぜこの仕組みが必要なのか。

今日はこれを掘り下げます。

第122章へようこそ。

第121章で、明示性を語りました。

Rustは暗黙の動作を排除し、何が起きているかをコードに書かせる。

今日のテーマは「式指向」です。

多くの言語には「文」と「式」の区別があります。

文は、何かを実行する命令。値を持たない。

式は、何かを計算して、値を返す。

条件分岐を書くとき。

多くの言語では、if文は「文」です。

分岐の中で変数に代入するという命令を実行する。if文そのものは値を返さない。

Rustでは、ifは式です。

ifそのものが値を返す。

分岐の結果をそのまま変数に束縛できる。

この設計は、単なる構文の好みではありません。

Rustの思想と深く結びついた、意図的な選択です。

第121章へようこそ。

第120章で、ゼロコスト抽象を語りました。

抽象化のコストがコンパイル時に消え、実行時に残らない。

そして、コストが発生する場面ではそれがコードに明示される。

今日のテーマは「明示性」です。

Rustを書いていると、他の言語では自動的に行われることを、自分の手で書かなければならない場面に出会います。

コピーが自動で起きない。cloneと書かなければならない。

型の変換が暗黙に起きない。変換関数を呼ばなければならない。

エラーが例外として飛ばない。Resultを受け取って処理しなければならない。

最初は不便に感じる。

なぜ言語が自動でやってくれないのか。

しかし、この不便さには明確な設計意図があります。

Rustは、プログラムの中で何が起きているかを、コードに書かせる。

暗黙のうちに何かが起きることを、構造的に拒否する。

第15章で、関数呼び出しのたびにスタックフレームが積まれることを学びました。

第16章で、キャッシュがCPUとメインメモリの速度差を埋めることを学びました。

今日は、もう少し視野を広げます。

プログラムが動いているとき、メモリはどのように区画されているのか。

どの領域に何が置かれ、誰がそれを管理しているのか。

プログラムが使うメモリには、性質の異なる領域があります。

その中でも特に重要な2つが「スタック」と「ヒープ」です。