【ITニュース解説】14 CS fundamental questions to prepare for your next interview & not sound like a vibe-coder!

システムエンジニアとして、プログラムの動作原理や効率、そして潜在的な脆弱性を理解することは非常に重要だ。これから、日々の開発で直面する可能性のあるいくつかの基本的な疑問について解説する。

まず、プログラムのパフォーマンス最適化について考える。 「switch文はif-else文の連続よりも常に効率的か」という疑問がある。多くの場合、コンパイラはswitch文を効率的なジャンプテーブルに変換するため、複数の条件を評価する必要があるif-else文の連続よりも高速になる可能性がある。しかし、条件の数や種類によっては、コンパイラがif-else文を同等かそれ以上に最適化することもあるため、常にswitchが優位とは限らない。現代のコンパイラは非常に賢く、多くの場合、開発者が書いたコードを最適な機械語に変換してくれる。

次に、「関数呼び出しによってどれくらいのオーバーヘッドが発生するか」について。関数を呼び出す際には、現在実行中の場所（リターンアドレス）を保存し、引数を渡し、呼び出された関数のためのメモリ領域（スタックフレーム）を確保するといった一連の処理が必要になる。これらの処理は「オーバーヘッド」と呼ばれる。非常に小さな関数を頻繁に呼び出す場合、このオーバーヘッドが無視できない影響を与えることがある。しかし、通常は関数のまとまりや再利用性といった利点のほうが大きく、過度にオーバーヘッドを心配する必要はない。コンパイラには「インライン化」という最適化機能もあり、小さな関数呼び出しを直接そのコードで置き換えることでオーバーヘッドを削減する場合もある。

「whileループはforループよりも効率的か」という質問だが、これは基本的に違いはない。どちらのループも、コンパイラが最終的に生成する機械語コードは同じか非常に似たものになることがほとんどだ。forループは初期化、条件判定、更新が一行で書けるためコードの可読性が高い一方、whileループは条件判定のみに特化しているため、よりシンプルに見える場合がある。どちらを使うかは、開発者が書きたいロジックの種類や可読性を重視するかに依存する。

「ポインタ参照は配列インデックスよりも効率的か」という点については、かつてはポインタ演算の方が高速だとされることがあった。ポインタはメモリアドレスを直接扱うため、配列インデックスのようにベースアドレスにインデックスを乗算するといった計算が不要になる場合があるからだ。しかし、現代のコンパイラは配列インデックスも非常に効率的に処理し、ポインタ演算とほぼ同等か、あるいは特定の状況では配列インデックスの方がキャッシュの利用効率などで優れることもある。重要なのは、どちらを使うかよりも、メモリにどのようにアクセスしているかを理解することだ。

「ローカル変数に合計する方が、参照渡しされた引数に合計するよりもループが速く実行されるのはなぜか」という疑問は、主にCPUのキャッシュメモリの動作とメモリへのアクセス方法に関係する。参照渡しされた引数は、その変数がメモリ上のどこかに存在し、ループのたびにそのメモリ位置にアクセスして値を更新する必要がある。一方、ローカル変数はCPUのレジスタやキャッシュメモリに近い位置に割り当てられる可能性が高く、高速にアクセスできる。特にループ内で頻繁に更新される変数がレジスタに保持されると、メモリへのアクセスが大幅に減り、結果として処理が高速になる。これは「キャッシュ局所性」の原則とも関連している。

「算術式の括弧を並べ替えるだけで関数が速く実行されることがあるのはなぜか」という問いは、一見すると不思議に思える。数学的には結果が変わらないはずだからだ。しかし、これはCPUの並列処理能力を最大限に引き出すためのコンパイラ最適化に関係している。たとえば、(a + b) + (c + d) のような式では、CPUは (a + b) と (c + d) を同時に計算し、その後でその二つの結果を合計できる可能性がある。一方、((a + b) + c) + d のような式では、前の計算結果が出ないと次の計算に進めないため、並列化の機会が減る。コンパイラはこのような並列化の可能性を探り、計算順序を調整することで高速化を図る。

次に、リンク時エラーの理解に進もう。 「リンカーが参照を解決できない」とは、プログラム内で使われている関数や変数の「名前」が見つからない、という意味だ。ソースコード上では関数を呼び出しているのに、その関数の実際の処理（定義）がどこにも存在しない、あるいはライブラリが適切にリンクされていない場合にこのエラーが発生する。これは「未定義参照エラー」とも呼ばれ、プログラムが実行可能ファイルとして完成できないことを示している。

「静的変数（static variable）とグローバル変数（global variable）の違い」について。グローバル変数はプログラム全体からアクセス可能で、プログラムの実行開始から終了までメモリ上に存在し続ける。一方、静的変数は関数内で定義された場合はその関数内からのみアクセス可能で、グローバル領域に定義された場合は定義されたファイル内からのみアクセス可能、というように、アクセス可能な範囲（スコープ）が限定される。しかし、どちらもプログラムの実行期間中メモリ上に存在し、一度だけ初期化されるという共通点がある。重要なのは、静的変数はそのスコープが限定されるため、他の部分からの意図しない変更を防ぎ、カプセル化を助けるという点だ。

「異なるCファイルで同じ名前のグローバル変数を二つ定義すると何が起こるか」という質問への答えは、リンカーが「多重定義エラー」を報告するというものだ。グローバル変数はプログラム全体で一意である必要がある。もし複数のファイルで同じ名前のグローバル変数が定義されていた場合、リンカーはどの変数を参照すべきか判断できず、矛盾が生じるためエラーを出す。これを避けるためには、グローバル変数を定義する際は、一つのファイルで定義し、他のファイルではexternキーワードを使ってその変数が外部ファイルで定義されていることを宣言するのが一般的だ。

「静的ライブラリ（static library）と動的ライブラリ（dynamic library）の違い」も重要だ。静的ライブラリは、コンパイル時にそのライブラリのコードが直接実行可能ファイルに組み込まれる。結果として実行可能ファイルのサイズは大きくなるが、ライブラリが単体で動作するため、他の環境への持ち運びが容易になる。一方、動的ライブラリは、コンパイル時にはライブラリの参照情報のみが実行可能ファイルに組み込まれ、実際のライブラリコードはプログラム実行時に読み込まれる。これにより実行可能ファイルのサイズは小さくなり、複数のプログラムで同じライブラリを共有できるためメモリ使用量を抑えられる。また、ライブラリを更新する際に、個々のプログラムを再コンパイルする必要がないという利点もある。

「コマンドラインでライブラリをリストする順序が重要なのはなぜか」という疑問への答えは、リンカーがシンボルを解決する順序に関係している。リンカーは通常、コマンドラインで指定された順序でライブラリを検索し、未解決のシンボル（関数や変数）を見つけようとする。もしライブラリAがライブラリBの機能を使っている場合、ライブラリBがライブラリAよりも先にリストされていないと、リンカーはライブラリAが必要とするシンボルを見つけられずにエラーを出す可能性がある。これは依存関係を適切に解決するためのルールだ。

「最も怖いことに、一部のリンカー関連エラーが実行時まで現れないのはなぜか」という質問は、動的ライブラリの特性と密接に関連している。静的ライブラリであればコンパイル時にすべてのシンボル解決が行われるため、リンクエラーはそこで発見される。しかし、動的ライブラリの場合、プログラム実行時にOSがライブラリを探して読み込むため、もし必要な動的ライブラリが見つからなかったり、互換性のないバージョンが読み込まれたりすると、プログラムの実行中にエラーが発生する。これは特に異なる実行環境でプログラムを動かす際に問題となりやすい。

最後に、セキュリティホールの回避について触れる。 「バッファオーバーフロー脆弱性とは何か」について。これは、プログラムが確保した固定サイズのメモリ領域（バッファ）に対して、その容量を超えるデータを書き込もうとしたときに発生する脆弱性だ。例えば、10文字分の領域しかない配列に20文字を書き込むと、余分な10文字が配列の隣接するメモリ領域を上書きしてしまう。この上書きによって、プログラムの制御フローを乗っ取ったり、機密情報を漏洩させたりするなどの悪意のある操作が可能になる場合がある。これは多くのセキュリティ攻撃の基本的な手法の一つだ。

「プログラムスタックとは何か」という問いへの答えは、プログラムが実行中に一時的なデータを格納するために使用するメモリ領域の一つ、というものだ。関数が呼び出されるたびに、その関数のローカル変数、引数、戻りアドレスといった情報がスタックに積まれる。関数から戻る際には、これらの情報がスタックから取り除かれる。バッファオーバーフローは、特にこのスタック上のバッファを越えてデータを書き込むことで、戻りアドレスを改ざんし、攻撃者が用意した不正なコードを実行させるために悪用されることが多い。このため、スタックの仕組みを理解し、安全なプログラミングを心がけることがセキュリティ上極めて重要となる。

これらの基本的な質問は、日々のプログラミングにおける深い理解を助け、より堅牢で効率的なソフトウェア開発につながるだろう。