C言語における「循環インクルード問題」と責務分割による解決法

この記事を書く経緯

C言語でコードを書いている際、きれいに責務分割しようとしてヘッダファイルを分けたところ、循環インクルード問題に苦しめられました。
そこで、自分の理解を整理するため、そして同じようにこの問題に悩む人の助けになればと思いこの記事を書きました。

記事を書くのは初めてなので、拙い点もあるかと思いますが、温かい目で読んでいただけると嬉しいです。

まず循環員クルードとは何か

C言語では#includeによってヘッダファイルを読み込むと、その中身がテキストとして展開されます。
それにより、以下の状況で問題が発生します。

/*-------------*/
/*     main.h     */
/*-------------*/

#include "sub.h"
typedef struct s_main { 
    int x; 
}    t_main;


/*-------------*/
/*     sub.h     */
/*-------------*/

#include "main.h"
typedef struct s_sub 
{
    t_main *a; 
}    t_sub;

このとき：

main.h -> sub.h -> main.h -> sub.h -> ...

のように、無限に再帰的に読み込まれ、循環インクルードが発生します。
結果として、コンパイラは

`unknown type name` や 
`incomplete type`エラーを出力してしまいます。

⚠️ 2. なぜ問題になるのか

・再帰的依存でビルドが止まる
・ヘッダガードが効かない順序で読み込まれる場合がある
・依存爆発：1つのヘッダを修正すると、全ソースが再コンパイルされる
・責務が曖昧になる：どの層がどのデータを持つのか不明確になる

① include guard を使う

#ifndef MAIN_H
# define MAIN_H

// ...

#endif

この方法では無限再帰は防げるが、構造体依存の循環はこれだけでは防げない。

② 前方宣言/プロトタイプせんげん (Forward Declaration)

// sub.h で main.h をインクルードしない代わりに
typedef struct s_main t_main;

構造体の中身を触らない（ポインタ経由で使うだけ）ならこれで十分。
これで main.h を読まずに t_main * 型を使えるようになる。

③ include の方向を一方通行にする

層	内容	依存方向
上層	メインロジック（main）	🔽 下層へ
中層	データ構造	🔽 下層へ
下層	汎用ライブラリ	🔽 依存なし

📘 ルール：下層が上層を include してはいけない。
上層が下層を「見るだけ」。
これが「依存の一方向化」。

④ rootヘッダでまとめる

プロジェクト全体を管理するヘッダ（例：cub3D.h）を作り、
そこに必要な .h を順序正しく include する。

// hoge.h
#ifndef HOGE_H
# define HOGE_H

# include "a.h"
# include "b.h"
# include "c.h"
# include "d.h"

typedef struct s_hoge { t_data data; } t_hoge;

#endif

これで main.c はこの1枚だけ include すればOKになります。

💡 4. 設計の考え方（責任分割）

層 役割 includeするもの
下層 汎用的な道具 互いに依存しない
中層 機能単位 下層のみ
上層 アプリ全体 中層をまとめる

つまり：

「道具は使い手を知らない。使い手だけが道具を知っている。」
といった前提に準じてコードを書いていくといいことがある。

🚀 5. まとめ

問題	解決策
循環includeが起きる	includeの方向を一方向にする
型未定義エラー	前方宣言を使う
依存が複雑	rootヘッダで整理する
ビルドが重い	下層ほど独立させる

この概念はC言語だけでなく、
C++・Go・Python・Rust など、すべての言語で通用する「依存制御の基本思想」となります。
この「責務分割」を意識して設計できるようになると、
プロジェクトが拡張しやすく、壊れにくく、美しい構造になり、今後、リファクタリングがしやすくなったりデバッグが楽になったりなど、良いことが待ち受けていると思います。