C面接で=と==に詰まる人向けに、代入・比較・文字列・ポインタ・floatの落とし穴を7項目で整理。即答力を高める実例つきで解説するので、面接前に確認してください。
C の面接で `=` に関する質問に詰まる候補者の多くは、記号自体はすでに知っています。C における `=` の理解で問題なのは語彙ではありません。言語が直感的な予想からどこでずれるのかを誰も教えてくれなかったこと、そして面接官はそのギャップを露出させる 3 つか 4 つの質問を正確に知っていることです。このガイドでは、その 7 つの落とし穴を直接取り上げ、圧をかけられた場面でも声に出して筋道立てて考えられる具体例を示します。
== と =: 面接官が本当に気にしているミス
ただの টাইポではない টাইポ
条件式の中で本当は `==` を書くべきところに `=` を書いてしまうのは、単なる টাইपोではありません。これは、候補者の頭の中で 2 つの異なる操作がまだ分かれていないことを示しています。1 つは値を保存する操作、もう 1 つは関係を判定する操作です。C における `=` は代入演算子で、変数に値を入れ、その値そのものへ評価されます。`==` は等値演算子で、2 つのオペランドが等しいかどうかを判定し、1 か 0 に評価されます。これらは根本的に異なる役割です。面接官がまずこの違いを尋ねるのは、候補者が状態の変更と状態の確認を分けて考えられるかを見たいからです。
このミスが実コードで生き残る理由は、C の文法が条件式の中で代入を許しているからです。`if (x = 5)` はコンパイラに拒否されず、そのままコンパイルされて実行されます。GCC を含む多くのコンパイラは、警告が有効なら `warning: suggest parentheses around assignment used as truth value` のような警告を出しますが、それは設定している場合に限られます。その警告が唯一の安全装置です。
実際にはこう見える
最初の `if` ブロックは、`x` がそれ以前に何だったかに関係なく、常に実行されます。代入によってプログラムの状態が変わり、その後で条件は元の値ではなく代入された値を評価します。ある面接課題でこれを書いてしまった候補者は、GCC が `-Wall` で警告を出したから気づけたと言っていました。`-Wall` を有効にしていなければ、プログラムは動き、何かを出力し、見た目には正しく見えます。実際に `x` の中身を確認するまでは。
GCC の警告オプションのドキュメント では、まさにこのパターンを対象にする `-Wparentheses` が説明されています。練習中に `-Wall` を有効にするのは必須です。
C の比較演算子が true/false ではなく 1/0 を返す理由
C が実際に使う真偽値モデル
C の比較演算子は、デフォルトでは真偽値型を返しません。整数を返します。具体的には、条件が真なら `1`、偽なら `0` を返します。C99 では `_Bool` と `<stdbool.h>` が導入され、`true` と `false` をマクロとして使えるようになりましたが、内部の値は依然として 1 と 0 です。C89 で書く場合、あるいは単に `<stdbool.h>` をインクルードしない場合は、`true` というキーワード自体がありません。言語は条件文の中では 0 以外の整数を真、0 を偽として扱います。
面接でここを曖昧に「条件は true を返します」と言うと、Python や Java の前提を持ち込んでいるように聞こえます。より正確には、「1 か 0 に評価され、if 文は 0 以外を分岐条件として扱います」と答えるのが、理解の深さを示します。
実際にはこう見える
準備中にこれを実行した候補者は、`result` が `true` と表示されると思っていたそうです。1 が出たので、何かがおかしいと考えました。何もおかしくはありません。C ではそれがまさに正しい動作です。`1` は 0 以外の整数として `if` に渡され、ブランチが実行されます。そして言語は真偽を文字列として自動的に表現してはくれません。cppreference.com の C 標準リファレンス でも、関係演算子と等値演算子は 0 または 1 の `int` 値を返すと確認できます。
6 つの比較演算子を、推測せずに使い分ける
== と != だけではなく、全体を押さえる
C の等値演算子は `==` ですが、これは 6 つの比較演算子からなる大きな परिवारの一部です。これらはすべて同じ返り値の振る舞いを共有しており、条件が成り立てば 1、成り立たなければ 0 を返します。個別に丸暗記するのではなく、ひとまとまりとして捉えると、圧力のある場面でも考えやすくなります。6 つは `==`（等しい）、`!=`（等しくない）、`<`（より小さい）、`>`（より大きい）、`<=`（以下）、`>=`（以上）です。
実際にはこう見える
これは、準備ノートのページに載せておくべき短い参照例です。各行はそれだけで完結した意味を持ち、結果は演算子の定義から直接導かれます。cppreference の比較演算子ページ では、関係演算子と等値演算子がまとめて扱われ、この振る舞いが 6 つすべてで成り立つことが確認できます。
覚えておくべき唯一のことは、`<=` と `>=` は 2 文字の演算子であり、順序が重要だということです。`=<` は C として無効です。急いで書くと候補者が実際によくやるミスです。
if 文やループで壊れる比較を書かない
なぜ条件式でミスが表面化するのか
単独の比較式が間違った値に評価されても、それ自体は無害です。しかし、それが `if` やループ条件の中に入ると、制御フローのバグになります。どの分岐が実行されるか、ループが何回回るかが変わるからです。面接官が C の比較演算子を気にするのは、単独の式としてではなく制御フローの文脈でです。演算子自体は理解していても、条件で間違ったものを書いてしまうと、クラッシュも例外も出さず、見た目にはもっともらしい出力を返し、ロジックを丁寧に確認するまで誰も気づかないバグになります。
実際にはこう見える
面接準備のとき、ある候補者は `i` が 5 に達したかを確認しようとして 2 つ目の版を書いてしまいました。ループは終わりませんでした。`i = 5` という代入は、条件を通るたびに 5 に評価され、それは常に 0 以外なので、ループは永久に回り続けます。代入を条件式の中に置くことが有効な式としてコンパイルされる、C の扱いがこのようなコードを生き残らせます。
演算子の優先順位が、= と == を本当のバグに変える
2 回読まないと危険さが見えないバグ
C における `==` と `=` の違いは、両方の演算子が同じ式に現れたときにさらに危険になります。C の演算子優先順位は必ずしも直感的ではなく、比較に見える行が、コンパイラの解釈次第で黙って代入になることがあります。代入演算子は多くの比較演算子より優先順位が低いですが、その順序を知っていて初めて意味があります。多くの初心者はその表を記憶しておらず、左から右に読んで、見た目どおりのことが起きると想定してしまいます。
本当の落とし穴は `if (result = a == b)` のような式です。目には「a と b を比較した結果を代入している」と見えますが、実際にそうなります。ただしそれは `==` のほうが `=` より優先順位が高いからです。演算子の順番を入れ替えると、意味は完全に変わります。
実際にはこう見える
GCC は最初の版に対して `warning: suggest parentheses around comparison in operand of '='` を出します。その警告は本当に役に立っています。GCC の警告フラグのドキュメント では、`-Wparentheses` がまさにこのパターンをどう検出するかが説明されています。実務上の安全なルールは、1 つの式に両方の演算子が必要なら、優先順位に任せて黙って正しく解釈されることを期待するのではなく、括弧で順序を明示することです。
文字列では == が期待どおりに動かない
2 つの同じ文字列が同じものではない理由
C における文字列比較は、Python、Java、JavaScript で文字列を `==` で比較するのに慣れた候補者を驚かせる落とし穴です。C では文字列はメモリ上のどこかに置かれた文字配列であり、文字列変数やリテラルはその最初の文字へのポインタとして表現されます。`str1 == str2` と書いても、比較しているのは文字内容ではなく、2 つのメモリアドレスです。内容が同じでも別の場所に置かれた 2 つの文字列は、`==` では等しくなりません。
これは癖でもバグでもありません。C が文字列を `char *` ポインタとして表し、組み込みの比較セマンティクスを持つ第一級オブジェクトとして扱わないことの直接の結果です。それを理解すれば、`strcmp` が必要な理由は不自然ではなく、当然のものになります。
実際にはこう見える
`==` の結果が実装依存なのは、一部のコンパイラが文字列リテラルを内部で共有し、同じアドレスに置くことがあるからです。そのため `s1 == s2` がたまたま 1 を返してしまうことがあります。これがバグをさらに悪化させます。あるコンパイラでは通り、別のコンパイラでは落ちるからです。`==` で文字列リテラルを比較しようとして `strcmp` を見つけるまで数時間を費やした候補者は、それを「C の準備で一番混乱した 30 分だった」と表現していました。自分の環境では動くのに採点環境で失敗したからです。strcmp の Linux man ページ には正しい方法が示されています。`strcmp` は文字列が等しければ 0、辞書順で前なら負、後なら正を返します。
ポインタの等価性は値の等価性ではない
面接官が本当に尋ねているアドレスの話
C で `==` を使ったポインタ比較は、2 つのポインタが同じアドレスを持つか、つまりメモリ上の同じ場所を指しているかを調べます。そこに格納されている値が等しいかどうかは調べません。面接官がこれを尋ねるのは、候補者がこの 2 つをしばしば混同するからです。「等しいかを調べています」と言うだけでは、何に対して等しいのかが曖昧です。印象が良い答えは、その違いを即座に名前で言える答えです。
実際にはこう見える
デバッグ中に、ある候補者はリンクリストの 2 つのノードが同じデータを持っているかを確認していました。`if (node1 == node2)` と書いたのに、値が一致しているのに分岐が一度も実行されない理由が分からなかったのです。ポインタ比較は技術的には正しく、`node1` と `node2` が別オブジェクトであることを正しく判定していました。しかし本当の目的は `node1 == node2`、つまり格納された値の比較でした。違いは 1 文字（`*`）ですが、意味の問いはまったく別です。
浮動小数点の等価比較は、当たり前に見えて当たり前ではない落とし穴
なぜ多くの float 判定で == は不適切なのか
C の浮動小数点数は、有限精度の 2 進数で保存されます。0.1 のような単純な小数でも、その多くは 2 進浮動小数点では正確に表現できません。float で計算を行うと、誤差がハードウェアレベルで蓄積されます。数学的には等しいはずの 2 つの値でも、2 進表現ではわずかに異なることがよくあり、その場合 `==` は 0 を返します。表示上は同じに見えてもです。
これは C 特有の問題ではありません。IEEE 754 浮動小数点表現 に由来するもので、ほぼすべての現代の言語とプロセッサで使われている標準です。C はこれを隠さず、そのままハードウェアに近い形で見せます。
実際にはこう見える
浮動小数点比較の正しい方法は、許容誤差を使うことです。
準備中に簡単な電卓を作っていた候補者は、`0.1 + 0.2 == 0.3` が false になるテストケースのデバッグに 1 時間かかりました。小数点以下 2 桁で表示すると、値は同じに見えました。表示精度を上げて初めて、丸めの違いが見えるようになったのです。面接官がこうした答えを好むのは、候補者が構文だけでなくハードウェアを理解していることを示すからです。
Verve AI が、C における equals の理解を伴う面接対策をどう助けるか
この文章で整理してきた構造上の問題は、これら 7 つの落とし穴が珍しいからではありません。紙の上では知っていても、実際の問いかけの場で筋道立てて説明するのは別の技能だからです。面接官に「C で文字列に `==` が使えないのはなぜですか？」と聞かれたとき、必要なのは正しいだけでなく、即答できる明快な説明です。それにはノートの読み返しではなく、現実に近い条件での反復練習が必要です。
Verve AI Interview Copilot は、まさにそのギャップを埋めるために作られています。リアルタイムで聞き取り を行い、用意された定型プロンプトではなく、あなたが実際に話した内容に応じて反応するので、候補者が最もつまずきやすいフォローアップ質問を練習できます。たとえば、`==` と `=` の違いは正しく説明できても、説明が少し曖昧だったとします。Verve AI Interview Copilot は「その式に対してコンパイラは実際には何をするのですか？」と切り返し、より正確に答えるよう促せます。この種の動的な圧力こそ、暗記した人と本当に理解している人を分けるものです。Verve AI Interview Copilot は本番のセッション中は見えない形で動作し、実際の面接直前まで使えます。equals 記号の質問で不安そうに聞こえるのをやめたいなら、最短ルートは、実際に応答できる相手に向かって声に出して答えることです。
FAQ
Q: C で == は何を意味し、= とどう違いますか？
`==` は等値演算子で、2 つの値が等しいかを判定し、1（true）または 0（false）を返します。`=` は代入演算子で、変数に値を保存し、その保存された値へ評価されます。決定的な違いは、`=` がプログラムの状態を変えるのに対し、`==` は状態を確認するだけだという点です。`if` 条件の中で `=` を書くのは C の文法として有効で、コンパイルも通るため、面接官はまさにこの違いを試します。
Q: なぜ C の比較は true/false ではなく 1/0 を返すのですか？
C89 の型システムにはネイティブな boolean 型がありません。関係演算子と等値演算子は、言語仕様上 `int` 値を返すよう定義されています。真なら 1、偽なら 0 です。C99 では `_Bool` と `<stdbool.h>` の `true` / `false` マクロが追加されましたが、これらはそれぞれ 1 と 0 に展開されます。条件文の文脈では、0 以外の整数は真として扱われます。
Q: if 文やループで ==, !=, <, >, <=, >= はいつ使えばよいですか？
厳密に一致するかどうかを見たいなら `==`、違いを検出したいなら `!=`、順序や範囲を表したいなら `<`, `>`, `<=`, `>=` を使います。ループでは、インデックスベースの反復では `<`（`i < n`）、番兵ベースの反復では `!=` がよく使われます。選ぶべき演算子は、テスト入力にたまたま合うものではなく、実際に答えたい意味論に合わせるべきです。
Q: 浮動小数点数を == で比較するのが危険なのはなぜですか？
浮動小数点数は有限精度の 2 進数で保存され、ほとんどの 10 進小数は正確に表現できません。float の計算では丸め誤差が蓄積するため、数学的には等しい 2 つの値でも、2 進表現ではわずかに異なることがよくあります。安全な代替は許容誤差を使う比較です。2 つの値の絶対差が許容できる epsilon より小さいかを確認し、通常は `<math.h>` の `fabsf` や `fabs` を使います。
Q: == が使えないなら、C で文字列を正しく比較するにはどうしますか？
`<string.h>` の `strcmp` を使います。2 つの文字列の文字内容を比較し、等しければ 0、最初の文字列のほうが辞書順で小さければ負、より大きければ正を返します。`==` が失敗する理由は、C の文字列変数がポインタだからです。`==` はテキスト内容ではなくメモリアドレスを比較します。別々のメモリ位置に置かれた同じ文字列は、`==` では等しくなりません。
Q: C の等価性に関する面接でよくあるミスは何ですか？
特に問われやすい 7 つは、条件で `==` の代わりに `=` を使うこと、比較結果が 1 か 0 だと知らないこと、ループで 6 つの比較演算子の 1 つを誤用すること、`=` と `==` を混ぜたときに括弧ではなく優先順位に頼ること、文字列比較に `strcmp` ではなく `==` を使うこと、値の比較が目的なのにポインタの等価性に `==` を使うこと、そして float 比較に許容誤差ではなく `==` を使うことです。どれも単独なら単純に見えますが、圧力がかかると本物のバグになります。
Q: C ではポインタ比較と値比較はどう違いますか？
`p1 == p2` は、2 つのポインタが同じメモリアドレスを持つか、つまり同じオブジェクトを指しているかを調べます。`p1 == p2` は、両方のポインタを先に参照し、そのアドレスに格納された値を比較します。これはまったく別の問いです。面接官がこれを試すのは、候補者が「等しいかを見ている」と言っても、何に対して等しいのかを明確にしないことが多く、それがアドレスの同一性と値の等価性を頭の中でまだ分離できていないサインだからです。
Conclusion
このガイドで取り上げた 7 つの落とし穴は、珍しい例外ではありません。C の設計が、初心者の直感ならこうなるはずだと思うところから外れる、まさにそのポイントです。そして面接官はそれを知っています。なぜなら、同じところでつまずく候補者を何度も見てきたからです。記号を丸暗記することが目的ではありません。`==` が文字列で失敗する理由、float に許容誤差が必要な理由、条件内の代入に対するコンパイラ警告が単なる提案ではない理由を、声に出して説明できることが目的です。
これらの質問で不安そうに聞こえなくなる最短の方法は、読むことではなく、答えを言う練習をすることです。7 つの落とし穴から 3 つ選び、記事を閉じて、それぞれを壁に向かって説明してみてください。説明につまずいたなら、そこが本当にまだ鍛えるべき点です。面接官に先に見つけられる前に。
Verve AI
コンテンツ