ビルドのときにヘッダファイルと静的リンクライブラリファイルが必要になる理由

Question

lib.*.aのようなバイナリファイル(静的リンクライブラリ)について、ビルドの際にこれらのファイルを指定すると同時に対応するヘッダファイルを別途指定する必要があるのはなぜですが？
リンカで複数のバイナリファイルを作るのが普通になった理由としては「逐一同じコード(ライブラリのコード部分)をコンパイルしているのが勿体ない」と言うのがあると思うのですが、なぜ与える必要があるのでしょうか。
どうせ後からライブラリの部分はリンクされるので、ヘッダファイルを与えてしまってコンパイルさせるのは無駄ではありませんか？
https://kamino.hatenablog.com/entry/c%2B%2B-principle-of-build-library
ここのブログを読ませていただいて思いました。

Comments

[episteme]

ヘッダ無しにどうやってコンパイルするんです?
# リンク時にはヘッダ要らんけど...

Answer 1

質問の趣旨を捉えられているかどうかちょっと自信がないのですが、

ライブラリファイルはリンクに必要な情報を持っているはずなのに、なぜ同様な情報を持った「ヘッダファイル」を別扱いにしてインクルードとかいうオマジナイをしなきゃいけないのか、ということでしょうか。

であるなら、私の思うところでは、
C言語が古いものだから
です。

Cが生まれたのは1970年代前半。そのころのコンピュータ事情を考えてみて下さい。
ソースにオブジェクトにライブラリ、そんな沢山のファイルを一気にまとめて置けるストレージも、それを受け入れるメモリも、一般で手に入るようなコンピュータは持っていませんでした。(そもそもコンピュータが「一般」で手に入ったかどうか)。そんな環境でCは頑張ったのです。関数や変数は、その情報だけあれば中身全部がソースになくても外部結合という形で部分毎に処理出来るようにしました。プリプロセス/コンパイル/アセンブル/リンクを各ステージ分けることで、各ステージごとのメモリ使用量も切り詰められるでしょう。
コンピュータの能力が足りなければ、そう、プログラマが代わりに苦労すればいいのです。複数のソースで共用する情報は、人間がコンパイル時に必要なものだけ切り出してヘッダファイルにしましょう。リンカはコンパイル結果のオブジェクトとライブラリだけ寄せ集めれば出来るようにしました。ライブラリの情報とヘッダファイルの同期? そんなのプログラマの責任で管理して下さい。
そんな匠の心を今に伝えているのが「ヘッダファイル」なのではないかと。

今どきの言語は、関連するファイルを全部どこかにまとめておけば、ファイル間で共有すべき情報は処理系が勝手に抽出してくれるのが普通ですよね。時代は変わったものです。

Comments

[Nawta]

なるほど！！
なんでヘッダにメソッドも何も全部かけるのにソースコードと分ける必要があるんだろうとすごく思っていたのですが、そうですね、コンパイル時にとりあえず必要な情報だけ書いとくといった用途にするためにはヘッダファイルという概念を作るのが一番良い気がします！
納得できました。ありがとうございます！！！

Answer 2

えっと、OSがどうやって実行可能ファイルを実行しているかですよね。OSはローダによって実行可能ファイルをメインメモリに読み込みます。そのときローダはプログラムが正しく動作するようにプログラムを「改変」します。C言語はコンパイラとリンカによって実行可能ファイルを生成することは分かっていますよね。コンパイラが生成するファイルのことをオブジェクトファイルと呼ぶことも。要はこういうことです。

ソースプログラム(.c) → [コンパイラ] → オブジェクトファイル(.o) → [リンカ] → 実行可能ファイル → [ローダ] → 実際に動作するコード

リンカとローダはシンボルを編集します。オブジェクトファイルと実行可能ファイルと実際に動作するコードはほとんど同じものです。何が違うかというと、実際に動作するコード以外はシンボルという「断片をつなぎ合わせるのに必要な情報」を持っているということです。

C言語はソースファイル単位で機械語を生成します。特殊なビルドチェーンでなければリンクのときに最適化を行いません。なぜそうするかというとコンパイルという処理がとても重いためです。コンパイルはソースファイルを読み込んで機械語に変換する作業です。できればこの作業は小分けで行いたいのです。したがってオブジェクトファイルというファイル形式が存在するのです。コンパイラは関数名をシンボルに変換します。ソース内で他のソースファイルの関数を呼び出している場合は「これこれのシンボルください」という情報に変換されます。

ヘッダファイルは複数のソースプログラムで関数宣言を共有するためのものです。これはC言語に型という概念が存在するために必要です。他のソースプログラムの関数を呼び出すとき、正しく呼び出すためにはその関数のインターフェースが必要になります。ここでいう「インターフェース」はJava言語のインターフェースと似ています。Javaのインターフェースはクラスによって実装されます。Cのヘッダファイルはソースプログラムによって実装されるのです。

静的リンクライブラリがどうして存在するかというと、コンパイル済みのコード片が必要だからであり、静的リンクライブラリはリンカによってオブジェクトファイルを集約したものになります。ここで再びリンカを使うことによってユーザーが書いたオブジェクトファイルと静的リンクライブラリをリンクさせることができます。

どうしてC言語ではヘッダファイルと静的リンクライブラリの２種類を用意しなければならないかということですが、C言語がアセンブリ言語の代替として登場したというのもあります。オブジェクトファイルはC言語だけでなくアセンブリコードからも生成されます。そこで静的リンクライブラリはアセンブリ言語と互換性のある部分であり、ヘッダファイルは純粋にC言語固有の部分なのです。

Answer 3

すでに出ていますが、関数の呼び出しにはその関数の戻り地・引数を定義した宣言が必要になります。
また、構造体・クラスを使用するならば、それらの定義も必要になります。

ライブラリ側のヘッダには、それらが記述されています。
もしヘッダファイルを提供しないとなれば、自分で記述しなければなりません。

例えば、以下の一般的なWin32のプログラム。

#include <windows.h>

LRESULT CALLBACK WindowProc(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
	switch (msg) {
	case WM_DESTROY :
		PostQuitMessage(0);
		break;

	default :
		return DefWindowProc(hWnd, msg, wParam, lParam);
	}
	return 0l;
}

int APIENTRY WinMain(HINSTANCE hInst, HINSTANCE hPrevInst, LPTSTR pszCmdLine, int nCmdShow)
{
	WNDCLASSEX wcx;
	HWND hWnd;
	MSG msg;

	wcx.cbSize = sizeof(WNDCLASSEX);
	wcx.style = CS_HREDRAW | CS_VREDRAW;
	wcx.lpfnWndProc = WindowProc;
	wcx.cbClsExtra = 0;
	wcx.cbWndExtra = 0;
	wcx.hInstance = hInst;
	wcx.hIcon = LoadIcon(NULL, IDI_APPLICATION);
	wcx.hCursor = LoadCursor(NULL, IDC_ARROW);
	wcx.hbrBackground = (HBRUSH)(COLOR_WINDOW + 1);
	wcx.lpszMenuName = NULL;
	wcx.lpszClassName = _T("MainWndClass");
	wcx.hIconSm = NULL;
	if (RegisterClassEx(&wcx) == 0) {
		return 1;
	}

	hWnd = CreateWindowEx(0, _T("MainWndClass"), _T("Hello"), WS_OVERLAPPEDWINDOW,
			CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT,
			NULL, NULL, NULL, NULL);
	if (hWnd == NULL) {
		return 1;
	}
	ShowWindow(hWnd, nCmdShow);
	UpdateWindow(hWnd);

	while (GetMessage(&msg, NULL, 0, 0)) {
		TranslateMessage(&msg);
		DispatchMessage(&msg);
	}

	return msg.wParam;
}

この中の、

#include <windows.h>

は、Microsoftが提供しているヘッダファイルです。
もしMicrosoftがヘッダファイルを提供しないとなれば、この一文の代わりに、以下のコードを自分で書く必要があります。

#define	NULL	((void *)0)
#define	_T(n)	L##n
typedef	long long	LRESULT;
#define	CALLBACK	
struct HWND__ { int unused; }; typedef	struct	HWND__ *	HWND;
typedef	unsigned int	UINT;
typedef	unsigned long long	WPARAM;
typedef	long long	LPARAM;
typedef unsigned long DWORD;
typedef unsigned short WORD;
typedef long LONG;
typedef void *LPVOID;
#define	WM_DESTROY	0x0002
void PostQuitMessage(int);
LRESULT DefWindowProcW(HWND, UINT, WPARAM, LPARAM);
#define	DefWindowProc	DefWindowProcW
#define	APIENTRY
struct HINSTANCE__ { int unused; }; typedef	struct HINSTANCE__	*HINSTANCE;
typedef	wchar_t *	LPTSTR;
typedef LRESULT ( *WNDPROC)(HWND,UINT,WPARAM,LPARAM);
struct HICON__ { int unused; }; typedef struct HICON__ *HICON;
struct HBRUSH__ { int unused; }; typedef struct HBRUSH__ *HBRUSH;
struct HMENU__ { int unused; }; typedef struct HMENU__ *HMENU;
typedef HICON HCURSOR;
typedef	const wchar_t *	LPCWSTR;
typedef struct tagWNDCLASSEXW {
	UINT cbSize;
	UINT style;
	WNDPROC lpfnWndProc;
	int cbClsExtra;
	int cbWndExtra;
	HINSTANCE hInstance;
	HICON hIcon;
	HCURSOR hCursor;
	HBRUSH hbrBackground;
	LPCWSTR lpszMenuName;
	LPCWSTR lpszClassName;
	HICON hIconSm;
} WNDCLASSEXW,*PWNDCLASSEXW,*NPWNDCLASSEXW,*LPWNDCLASSEXW;
typedef struct tagPOINT {
  LONG x;
  LONG y;
} POINT,*PPOINT,*NPPOINT,*LPPOINT;
typedef struct tagMSG {
	HWND hwnd;
	UINT message;
	WPARAM wParam;
	LPARAM lParam;
	DWORD time;
	POINT pt;
} MSG,*PMSG,*NPMSG,*LPMSG;
typedef struct tagPOINT {
  LONG x;
  LONG y;
} POINT,*PPOINT,*NPPOINT,*LPPOINT;
typedef WORD ATOM;
ATOM RegisterClassExW (const WNDCLASSEXW *);
#define	RegisterClassEx	RegisterClassExW
HWND CreateWindowExW(DWORD dwExStyle,LPCWSTR lpClassName,LPCWSTR lpWindowName,DWORD dwStyle,int X,int Y,int nWidth,int nHeight,HWND hWndParent,HMENU hMenu,HINSTANCE hInstance,LPVOID lpParam);
#define	CreateWindowEx	CreateWindowExW
#define	WS_OVERLAPPEDWINDOW	(0x00000000l | 0x00C00000l | 0x00080000l | 0x00040000l | 0x00020000l | 0x00010000l)
#define	CW_USEDEFAULT	((int)0x80000000)
#define	CS_HREDRAW	0x0002
#define	CS_VREDRAW	0x0001
HICON LoadIconW(HINSTANCE hInstance,LPCWSTR lpIconName);
#define	LoadIcon	LoadIconW
HCURSOR LoadCursorW(HINSTANCE hInstance,LPCWSTR lpCursorName);
#define	LoadCursor	LoadCursorW
#define	IDI_APPLICATION	((LPSTR)((ULONG_PTR)((WORD)(32512))))
#define	IDC_ARROW	((LPSTR)((ULONG_PTR)((WORD)(32512))))
#define	COLOR_WINDOW	5
typedef int WINBOOL;
WINBOOL ShowWindow(HWND hWnd,int nCmdShow);
WINBOOL UpdateWindow(HWND hWnd);
WINBOOL GetMessageW(LPMSG lpMsg,HWND hWnd,UINT wMsgFilterMin,UINT wMsgFilterMax);
#define	GetMessage	GetMessageW
WINBOOL TranslateMessage(const MSG *lpMsg);
LRESULT DispatchMessageW(const MSG *lpMsg);

どうですか、あなたはこれを書く気になりますか？
私は、書くんじゃなかったと後悔してます(笑)

(チクショウ、「gcc -E」でプリプロセッサ展開して一ファイルにすれば楽に書けるだろうとたかを括った)

Comments

[katsuko]

あ、一個ミス見つけた。
さらに言えば、Win32APIは静的ライブラリじゃないか。まぁ、理屈は同じですし、勘弁してください…。

[Nawta]

そうですね、C++系ではライブラリのファイルにはファイル間の依存関係などが保存されていないなど他の方の回答にもあったように、ヘッダファイルの必要性が礼を通じてすごくわかりました。理解が深まりました。ありがとうございます！！

Answer 4

補足的回答を。

ライブラリの配布方法はいくつかあります。

ヘッダーオンリーにしてしまう場合

この場合は利用者は単にヘッダーファイルをgit submoduleなりcmakeなり自力で引っ張ってきてinclude pathを通してincludeすれば利用できます。

C++のtempalteを多用するライブラリによく見られます。

利用しやすい半面、ビルド速度が遅くなりがちです。

ヘッダーオンリーにしない場合

ソースコードを配布する場合

ビルドのためのスクリプト(autotoolsの設定とかcmakeの設定とか)くらいはつけるけど、
をそのまま配布する場合。

利用者は予めビルドする必要があり、やや利用しにくいです。著名なソフトウェアならライブラリ作者ではなく第三者がビルドして公開している場合もあります。pacman, apt, yumなどの
パッケージマネージャなんかはその例です。またビルドスクリプトをパッケージにする例(vcpkgなど)もあります。

ビルド済のライブラリを配布する場合

静的/動的リンクライブラリとヘッダーファイルを配布します。

利用者はビルドする必要がありませんが、自分の環境向けのものが配布されていない場合はあります。またライブラリ製作者は必要な環境すべてに対してビルドしておかなければなりません。

ソースコードを開示する必要がないので、プロプライエタリソフトウェアなどに見られる他、利用者の多い環境向けに配布しているOSSもあります。

Comments

[Nawta]

ものすごくスッキリわかりました！メソッドのソースを見られたくない場合もあるのは何となくわかるので腑に落ちました！ありがとうございます

Answer 5

どうせ後からライブラリの部分はリンクされるので、ヘッダファイルを与えてしまってコンパイルさせるのは無駄ではありませんか？

いえ、ヘッダファイルがないと型情報が得られないため、コンパイルができません。

Javaや.NET Frameworkのような環境では、型情報もコンパイル後のオブジェクトファイルに保持されていますが、CやC++の場合は（デバッグ用は別として）コンパイル後のライブラリは実行コードだけで型情報が残らないので、ヘッダが必要です。

Comments

[Nawta]

なるほど、そうだったのですね。
ではヘッダファイルだけを配布する形式からオブジェクトファイル(静的リンクライブラリファイル)も配布する形式に移り変わったのはなぜなのですか？
ヘッダファイルだけ配布すれば十分ならばそっちの方がシンプルで良いのではと思ってしまいます。

[ozwk]

> Nawtaさん

一応ですけど、ヘッダファイルとソースコードは意味が違いますよ?
質問文に書いてあるブログの3.1も「ソースコードの配布」であって「ヘッダファイルの配布ではないです」

[退会済みユーザー]

一応ヘッダファイルだけで提供されているクラスライブラリも見たことはあります。
WTLがそうだったかな。

[episteme]

↑ぜーんぶtemplate(or inline)だったらそうなりますわね。

[Nawta]

ライブラリのソースファイルとヘッダファイルを分けるということが分かっていませんでした。。。今理解できました。みなさんご回答ありがとうございます！