C++ Way

Mon, 30 Oct 2023 02:11:25 +0900

背景

高速なアプリケーションを動かすにはC/C++が必須になる
Pythonで書くと遅くなり、重い腰を上げてC++をやることになったの
そのためにC++やCmakeの基礎的な疑問をAIにぶつけたので、答えをまとめた

全体像

C/C++ では、プログラムはふつう 1回で全部完成するのではなく、下の3つの流れで作られる。

前処理
コンパイル
リンク

`.h` と `.c` の役割

`.h`

宣言を書く場所

例:

1

int add(int a, int b);

上記のように、

関数名
引数の型
戻り値の型

を他のファイルに知らせ。

`.c`

実装を書く場所。

例:

1
2
3


int add(int a, int b) {
 return a + b;
}

上記のように、実際の処理の中身を書く。

なぜ `.h` と `.c` を分けるのか

小さいプログラムなら、1ファイルに全部書いても動く。でも複数ファイルになると、ある .c から別の .c の関数を使いたくなる。

たとえば

main.c
add.c
sub.c

があるとき、main.c は add() や sub() の存在を知らないと呼べない。

そのために .h を使って、複数の .c ファイルで共有する宣言をまとめるということ。

つまり .h は、

複数ファイルのための共通の説明書ということ。

`#include` の意味

1

#include "calc.h"

は、

その場所に calc.h の中身を貼り付ける

と思えばOK。

なので main.c に #include "calc.h" があると、コンパイラは main.c だけでなく、そこに貼られた calc.h の内容も見る。

`< >` と `" "`

#include <stdio.h> 標準ライブラリなど、システム側のヘッダを探す
#include "calc.h" 自分のプロジェクト内のヘッダを探す

`#include` は前処理

#include はコンパイルそのものではなく、前処理。

前処理の例

#include
#define
#ifndef

コンパイル

各 .c をそれぞれ .o にする

リンク

.o 同士をつないで実行ファイルにする

コンパイルとリンクの違い

たとえば

main.c
add.c
sub.c

があるとき、

1
2
3


gcc -c main.c # main.o
gcc -c add.c # add.o
gcc -c sub.c # sub.o

のように、各 .c は別々にコンパイルされる。

そのあとで

1

gcc main.o add.o sub.o -o app

として、最後に1つの実行ファイルへまとめる。

つまり、

.c 同士が自動で1つのソースになるわけではない
まず別々に .o を作る
最後にリンクして1つにする

なぜ `main.c` のコンパイル時に `add.c` の中身を見ないのか

gcc -c main.c の入力は基本的に main.c と、その中で #include されたものだけ す。

だからコンパイラは、main.c をコンパイルするときに add.c を勝手には見ない。

その代わり、add() の宣言が .h にあれば、

add という関数がある
引数は int, int
戻り値は int

と分かるので、main.c はコンパイルできる。

コンパイル時に実体はなくてもいいのか

はい、普通の関数ならコンパイル時には宣言があれば進められる。

つまり

コンパイル時: 宣言が必要
リンク時: 実装が必要

たとえば main.c が add() を呼んでいても、コンパイル時には

1

int add(int a, int b);

が分かっていればよいということ。

でも最終的にリンクするときに add() の本体がないと、

undefined reference

のようなエラーになる。

つまり、

コンパイラは「呼び方」を確認し、リンカは「本体の所在」を確認する

実装ファイルが自分のヘッダを include する理由

たとえば

1
2
3
4
5
6


// sub.c
#include "calc.h"

int sub(int a, int b) {
 return a - b;
}

のように、sub.c でもヘッダを include することがある。

これは sub.c が sub() を使うためではなく、

ヘッダに書いた宣言と、自分の実装が一致しているか確認するため

つまり、

main.c が include する → 使うため
sub.c が include する → 宣言と実装の答え合わせのため

include guard とは何か

ヘッダの先頭によくある

1
2
3
4
5
6


#ifndef ADD_H
#define ADD_H

...

#endif

これは include guard 。

これは、

同じヘッダが複数回読み込まれても、1回だけ有効にする

ための仕組み。

これは文法上の絶対ルールではなく、昔からの定番の書き方。

`.o`, `.a`, `.so`, `a.out`

`.o`

オブジェクトファイル各 .c / .cpp をコンパイルした結果

`.a`

静的ライブラリ複数の .o をまとめたもの

`.so`

共有ライブラリ（動的ライブラリ）これも元は .o から作るが、実行時に読み込まれる

`a.out`

実行ファイルのデフォルト名 gcc main.c のように -o を省略したときにできることがある

`.a` と `.so` の違い

どちらも元は .o から作れる。

.a = 静的ライブラリ
.so = 共有ライブラリ

違いは「元の材料」ではなく、できあがったものの使われ方。

.a はリンク時に実行ファイルへ取り込まれる
.so は実行時に外から読み込まれる

`ar rcs` の意味

1

ar rcs libmylib.a foo.o bar.o

は、.o をまとめて .a を作るarchiveコマンド。

r = 入れる / 置き換える
c = 新規作成
s = シンボル索引を作る

つまり

静的ライブラリを作って、リンクしやすい形に整える

ということ。

PICオプション

PIC とは何か

PIC = Position-Independent Code 位置独立コード。

これは、どのメモリアドレスに置かれても動きやすいコード。

共有ライブラリ .so を作るときによく使う。

1
2


g++ -fPIC -c foo.cpp -o foo.o
g++ -shared -o libmylib.so foo.o

PICで大事なこと

-fPIC は .o の作り方
.so はその .o から作る共有ライブラリ

です。

しかも、PIC な .o から .a を作ることもできます。つまり -fPIC は .a を禁止するものではなく、単に中身の .o の性質。

フォルダ構成

include / src / third_party

よくあるフォルダ構成は以下:

include/ = 公開ヘッダ
src/ = 実装（非公開）
third_party/ = 外部ライブラリ

SDKのパターン

include/ = 利用者に見せる API
src/ = SDK 作者の実装ソース
配布物 = include/ + ビルド済みライブラリ
利用者 = ヘッダを include して、そのライブラリにリンク

Makefile / CMake

今までのmain.c、add.c、sub.c、calc.hを使う場合は以下のようになる。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


app: main.o add.o sub.o
 gcc main.o add.o sub.o -o app

main.o: main.c calc.h
 gcc -c main.c -o main.o

add.o: add.c calc.h
 gcc -c add.c -o add.o

sub.o: sub.c calc.h
 gcc -c sub.c -o sub.o

clean:
 rm -f *.o app

もしくはもっときれいにかける。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


CC = gcc
CFLAGS = -Wall -Wextra

app: main.o add.o sub.o
 $(CC) main.o add.o sub.o -o $@

%.o: %.c calc.h
 $(CC) $(CFLAGS) -c $< -o $@

clean:
 rm -f *.o app

CMakeの場合は以下になる。

1
2
3
4
5
6
7
8


cmake_minimum_required(VERSION 3.16)
project(calc C)

add_executable(app
 main.c
 add.c
 sub.c
)

まとめ

一言でまとめると、

C/C++ では、ヘッダに宣言、ソースに実装を書き、各ソースを別々にコンパイルし、最後にリンクでつなぐ。

さらにもう少しかみ砕くと、

.h は「こう使ってね」という説明書
.c / .cpp は実際の中身
#include は説明書を貼り付ける前処理
コンパイルは各ファイルを別々に処理
リンクはバラバラの結果を最後につなぐ

最後に超短く言うと:

宣言を共有するために .h
実装を書くために .c / .cpp
コンパイルで .o
リンクで実行ファイル
.a と .so はどちらも .o から作れるが、使い方が違う

参考文献

ld(1) - Linux manual page

C++ on M1KE BL0G

C++ Way

背景

全体像

.h と .c の役割

.h

.c

なぜ .h と .c を分けるのか

#include の意味

< > と " "

#include は前処理

前処理の例

コンパイル

リンク

コンパイルとリンクの違い

なぜ main.c のコンパイル時に add.c の中身を見ないのか

コンパイル時に実体はなくてもいいのか

実装ファイルが自分のヘッダを include する理由

include guard とは何か

.o, .a, .so, a.out

.o

.a

.so

a.out

.a と .so の違い

ar rcs の意味

PICオプション

PIC とは何か

PICで大事なこと

フォルダ構成

include / src / third_party

SDKのパターン

Makefile / CMake

まとめ

参考文献

`.h` と `.c` の役割

`.h`

`.c`

なぜ `.h` と `.c` を分けるのか

`#include` の意味

`< >` と `" "`

`#include` は前処理

なぜ `main.c` のコンパイル時に `add.c` の中身を見ないのか

`.o`, `.a`, `.so`, `a.out`

`.o`

`.a`

`.so`

`a.out`

`.a` と `.so` の違い

`ar rcs` の意味