はじめてのC言語 | 第８回
ポインタは「ロケーション札」を持って動く
カフェのバックヤードを想像してみてください。
表のカフェスペースは、
「注文して、受け取って、ゆったり作業する」場所です。
でも奥のバックヤードは、少し違います。
棚が並び、箱が積まれ、
必要なものを、必要な場所から、すばやく取り出す世界です。
C言語のポインタは、
そのバックヤードで使う 「ロケーション（場所）」 にとてもよく似ています。
- 商品そのものを持つのではなく
- 商品が置かれている場所を持つ
それが、ポインタの発想です。
まずは基本：ポインタが持っているのは「値」ではなく「場所」
C言語では、変数には「値」が入ります。
でもポインタ変数は、ちょっと違って、
“値の入っている場所（アドレス）” を入れるための箱です。
バックヤードで言うと、こうです。
- 野菜そのものを持ってくるのではなく
- 「野菜棚の、3段目、右から2番目」みたいな 場所の札 を持つ
この札があると、ナミちゃんは、後輩にこう言う風に伝えられます。
「この場所にあるものを取ってきて」
記号は2つだけ：& と *
ここは、肩の力を抜いて大丈夫です。
最初に覚えるのは、2つだけです。
&（アンド）は「場所を示す記号」
&x は、x の置き場所を示しています。
- ナミちゃんが「この野菜、どこに置いてあるの？」と棚番号を見る感じ
*（アスタリスク）は、示された場所にある「中身を扱う」
*p は、p が示している場所にある中身を見たり／使ったりするための記号です。
- ナミちゃんが「その棚に行って、商品を取り出す」感じ
ナミちゃん、野菜を取りに行く
ある日、ナミちゃんはキッチンから言われました。
「トマト、取ってきて〜！」
ナミちゃんはメモを見ます。
「野菜棚のロケーション：V-02」
この V-02 が、まさにポインタです。
「トマトそのもの」ではなく、トマトがある場所を指しています。
ナミちゃんは、ロケーション札を頼りに、棚へ向かいました。
行ってみたら…棚がない（＝指している場所が変？）
ところが。
「……あれ？V-02 の棚が、そもそも無い。」
これはC言語だと、かなり危ない状態です。
ポインタが指している場所が、
実在しない場所だったり、すでに壊れていたりしても、
そこで中身を取ろうとしてしまいます。
結果として起きやすいのが、
- いきなり落ちる（クラッシュ）
- 変な値が出る
- たまに動くけど、ある日突然壊れる
こういう「怖さ」です。
C言語では、これらをまとめて 未定義動作 と呼びます。
“何が起きてもおかしくない” という意味です。
棚はあるけど、商品がない（＝中身が無い、または別のもの）
次のパターン。
棚はある。でも中身は空っぽ。
「えっ、トマト無い……」
これも、ポインタの世界でよく似たことが起きます。
- 指している場所は存在する
- でも中身が、期待したものではない
バックヤードだと、
- 誰かが出荷して空になった
- 入荷前だった
- 別の商品に差し替わっていた
C言語だと、
- まだ値を入れていない（初期化していない）
- すでに解放したメモリを使ってしまった
- 型の違うものを、間違って読んでいる
こういう事故につながります。
ロケーションを変えずに、商品だけ移動した（＝商品が行方不明・・）
ナミちゃんが一番困るのは、このパターンです。
ロケーション札は V-02 のまま。
でも実際のトマトは、別の棚に移動していた。
「場所の札は合ってるのに、現物がいない……」
C言語でも似ています。
ポインタは「場所」を参照します。
だから、場所の管理がズレると、
- 関係ないデータを読んでしまう
- うっかり別の場所を書き換えてしまう
という形で、静かに事故が起きます。
ここで、配列や文字列につながってくる
C言語では、配列や文字列を扱うとき、
この「場所の考え方」がとてもよく出てきます。
配列は「並んだ箱」でした。
そしてポインタは「箱の場所を指す札」です。
つまり、
- 配列の先頭の場所を指して
- そこから順番にたどっていく
この発想が自然に出てきます。
だから、ポインタが分かると、
配列や文字列が“急に一本の線でつながる”瞬間が来ます。
危険を避けるコツ（バックヤードで事故を起こさないために）
ここからは、ナミちゃんが安全に動くためのルールです。
ポインタは便利ですが、安全に管理しないと、
バックヤードはすぐ事故現場になります。
ロケーション札は「空っぽのまま使わない」
バックヤードで、ロケーション札が白紙だったら危険です。
どこへ行くか分からないからです。
C言語でも同じで、初期化されていないポインタは危険です。
- 使う前に、必ず「指す先」を決める
- まだ決められないなら、いったん NULL にしておく
NULLは「まだ行き先が無い」という札です。
NULLなら「取りに行かない」
ナミちゃんがメモを見て、
「ロケーション：なし」
だったら、棚に走りません。
まず確認します。
C言語でも、
NULLかもしれないポインタを、
いきなり * で触らない。
というのが鉄則です。
“棚番号の範囲” を必ず守る（配列の外に出ない）
バックヤードでは、棚の段数には限界があります。
- 3段しかないのに、5段目を探しに行ったら危ない
C言語でも、
- 配列の範囲外を読んだり書いたりしない
- 「何個あるか（サイズ）」を一緒に管理する
これだけで事故が激減します。
“もう使わない棚” の札を握りしめ続けない（古い棚札は捨てる）
バックヤードでも、
- 仮置きの棚を片付けたのに
- 古いロケーション札だけ残っている
これ、かなり危険です。
C言語では、これに近いのが
- すでに終わった領域を指す（ダングリングポインタ）
- 解放済みメモリをまた使う
という事故です。
「片付けたら、札も捨てる」
つまり、不要になったら NULLに戻す と安全です。
迷ったら、道具を使って点検する（事故の早期発見）
バックヤードでも、
棚の番号が怪しいときは、点検します。
C言語でも、次の道具が助けになります。
- コンパイラ警告を強める（警告は“注意喚起”）
- 実行時チェック（Sanitizerなど）
- メモリ検査ツール（Valgrindなど）
「事故が起きたあと」ではなく、
「事故になりそうな瞬間」を見つけるための道具です。
まとめ：ポインタは “場所の扱い” に慣れるための鍵
ナミちゃんのバックヤードの話で言うと、
- ポインタは「商品」ではなく「ロケーション」
&は「場所を示す」記号*はその場所にある「中身を扱う」記号- 場所がズレると、事故（クラッシュや誤動作）につながる
- だからこそ、初期化・NULLチェック・範囲・寿命の管理が大切
ポインタは、怖いものというより、
「場所を扱うための道具」です。
バックヤードで安全に動けるようになると、
C言語の景色は、ぐっと見通しがよくなってきます。
さらに学びたいあなたへ
📘 用途ごとに選ぶ Linux のおすすめ本
