C/C++ on M1KE BL0G

C++ Way

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

背景

高速なアプリケーションを動かすには C/C++ が有用
Python だけでは重くなる処理があり、C++ を使う必要が出てきた
この記事では、C++ が C と比べて何を追加しているのか、C++ らしい考え方を整理する

C++とは

C++ は、C をベースにしつつ、より大規模なプログラムを書きやすくするための機能を追加した言語。

C に対して、主に以下のような機能が追加されている。

クラス
コンストラクタ / デストラクタ
参照
関数オーバーロード
名前空間
テンプレート
STL
例外
virtual によるポリモーフィズム
RAII
スマートポインタ
move semantics
constexpr

C++ は単に「Cにクラスを足した言語」ではなく、
リソース管理、抽象化、型安全性、汎用プログラミングを強く意識した言語。

CとC++の大きな違い

C は、比較的シンプルな言語。

主に、

関数
構造体
ポインタ
手動メモリ管理

を使ってプログラムを書く。

一方 C++ は、C の機能に加えて、

オブジェクト指向
ジェネリックプログラミング
RAII による自動的なリソース管理
標準ライブラリによる便利なデータ構造
コンパイル時処理

などを使える。

つまり C++ は、C よりも高い抽象度で書ける。

ただし、抽象度が高い一方で、機能が多く、言語仕様もかなり複雑。

C++の基本思想

C++ でよく言われる考え方に、zero-overhead abstraction がある。

これはざっくり言うと、

使わない機能のコストは払わない。
使う機能も、手書きと同じくらい効率的であるべき。

という考え方。

つまり C++ は、抽象化しながらも、できるだけ実行時の無駄を増やさないことを目指している。

たとえば std::vector やテンプレートは高級な仕組みに見えるが、うまく使えばかなり効率よく動く。

クラス

C++ の大きな特徴の1つがクラス。

クラスは、データと処理をまとめる仕組み。

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


class Counter {
private:
 int value;

public:
 Counter() : value(0) {}

 void increment() {
 value++;
 }

 int get() const {
 return value;
 }
};

使う側はこう。

1
2
3
4


Counter c;
c.increment();

int v = c.get();

C の struct は基本的にデータをまとめるものだったが、C++ の class はデータと関数を一緒に持てる。

`struct` と `class` の違い

C++ では struct もメンバ関数を持てる。

1
2
3
4
5
6
7
8
9


struct Point {
 int x;
 int y;

 void move(int dx, int dy) {
 x += dx;
 y += dy;
 }
};

C++ の struct と class の主な違いは、デフォルトのアクセス指定。

1
2


struct = デフォルト public
class = デフォルト private

つまり、以下は public。

1
2
3


struct A {
 int x;
};

以下は private。

1
2
3


class B {
 int x;
};

コンストラクタ

コンストラクタは、オブジェクトが作られるときに自動で呼ばれる関数。

1
2
3
4
5
6
7


class User {
private:
 std::string name;

public:
 User(const std::string& n) : name(n) {}
};

使う側。

1

User user("Alice");

C では初期化処理を自分で関数として呼ぶことが多い。

1

user_init(&user);

C++ では、オブジェクト生成時に初期化処理を自動で走らせることができる。

デストラクタ

デストラクタは、オブジェクトが破棄されるときに自動で呼ばれる関数。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


class File {
public:
 File() {
 // ファイルを開く
 }

 ~File() {
 // ファイルを閉じる
 }
};

C++ では、スコープを抜けたときに自動でデストラクタが呼ばれる。

1
2
3


{
 File f;
} // ここで f のデストラクタが呼ばれる

この仕組みが、C++ の RAII につながる。

RAII

RAII は Resource Acquisition Is Initialization の略。

日本語にすると少し分かりにくいが、ざっくり言うと、

リソースの確保と解放を、オブジェクトの寿命に結びつける

という考え方。

たとえば、ファイルを開いたら必ず閉じる必要がある。

C ではこう書く。

1
2
3
4
5
6
7
8
9


FILE* fp = fopen("data.txt", "r");

if (fp == NULL) {
 return;
}

/* 何か処理 */

fclose(fp);

でも途中で return したり、エラーが起きたりすると、fclose を忘れる可能性がある。

C++ では、オブジェクトのデストラクタに後始末を書ける。

1
2
3
4
5


{
 std::ifstream file("data.txt");

 // 何か処理
} // スコープを抜けると自動で close される

このように、リソース解放を自動化できるのが RAII。

C++ ではかなり重要な考え方。

参照

C++ には参照がある。

1
2
3


void increment(int& x) {
 x++;
}

使う側。

1
2


int a = 10;
increment(a);

結果として a は 11 になる。

C ならポインタを使うことが多い。

1
2
3


void increment(int* x) {
 (*x)++;
}

C++ の参照は、ポインタよりも「別名」に近い。

1
2
3
4
5


int a = 10;
int& ref = a;

ref = 20;
// a も 20 になる

参照を使うと、ポインタより読みやすく書ける場面がある。

`const`

C++ では const がよく使われる。

1
2
3


void print(const std::string& s) {
 std::cout << s << std::endl;
}

これは、

1
2


s をコピーせずに参照で受け取る
ただし中身は変更しない

という意味。

C++ では、大きなオブジェクトを関数に渡すときに、

1

const T&

で受け取ることがよくある。

関数オーバーロード

C++ では、同じ名前の関数を引数違いで複数定義できる。

1
2
3
4
5
6
7


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

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

使う側。

1
2


add(1, 2); // int版
add(1.5, 2.5); // double版

C では同じ名前の関数を複数定義できない。

C++ では、引数の型や数によって呼び分けられる。

名前空間

C++ には名前空間がある。

名前の衝突を防ぐための仕組み。

1
2
3
4
5


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

使う側。

1

int result = math::add(1, 2);

標準ライブラリの std::vector や std::string の std も名前空間。

1
2


std::vector<int> v;
std::string s;

テンプレート

テンプレートは、型をパラメータにできる仕組み。

1
2
3
4


template <typename T>
T add(T a, T b) {
 return a + b;
}

使う側。

1
2


add<int>(1, 2);
add<double>(1.5, 2.5);

型を省略できることもある。

1
2


add(1, 2);
add(1.5, 2.5);

テンプレートを使うと、型に依存しない汎用的なコードを書ける。

C++ の STL もテンプレートを多用している。

STL

STLとは

STL は Standard Template Library の略。

C++ 標準ライブラリのうち、特に汎用データ構造とアルゴリズムの仕組みを指す言葉。

現在はやや広めに、「C++ 標準ライブラリの便利な部品群」くらいの意味で使われることも多い。

STL の中心になるのは以下。

コンテナ
アルゴリズム
イテレータ

コンテナ

コンテナは、データを入れる箱。

代表例。

std::vector
- 可変長配列
std::string
- 文字列
std::map
- キーと値の対応表
std::unordered_map
- ハッシュマップ
std::set
- 重複なし集合
std::deque
- 両端キュー
std::list
- 双方向リスト

例。

1
2
3


#include <vector>

std::vector<int> v = {1, 2, 3};

アルゴリズム

アルゴリズムは、データを処理する関数群。

代表例。

std::sort
std::find
std::copy
std::remove
std::transform

例。

1
2
3
4
5
6


#include <vector>
#include <algorithm>

std::vector<int> v = {3, 1, 2};

std::sort(v.begin(), v.end());

この場合、

std::vector がコンテナ
std::sort がアルゴリズム

イテレータ

イテレータは、コンテナの中身をたどる仕組み。

代表的には以下を使う。

1
2


begin()
end()

例。

1
2
3
4
5
6
7
8


#include <vector>
#include <iostream>

std::vector<int> v = {1, 2, 3};

for (auto it = v.begin(); it != v.end(); ++it) {
 std::cout << *it << std::endl;
}

vector でも set でも、似た形で処理できるのはイテレータのおかげ。

例外

C++ には例外処理がある。

1
2
3
4
5
6
7
8
9


#include <stdexcept>

int divide(int a, int b) {
 if (b == 0) {
 throw std::runtime_error("division by zero");
 }

 return a / b;
}

受け取る側。

1
2
3
4
5


try {
 int x = divide(10, 0);
} catch (const std::exception& e) {
 std::cout << e.what() << std::endl;
}

C ではエラーコードで失敗を返すことが多い。

1
2
3
4
5


int result = do_something();

if (result != 0) {
 // エラー処理
}

C++ では、エラーを例外として伝えることができる。

ただし、プロジェクトによっては例外を禁止することもある。

継承

C++ には継承がある。

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


class Animal {
public:
 void eat() {
 std::cout << "eat" << std::endl;
 }
};

class Dog : public Animal {
public:
 void bark() {
 std::cout << "bow" << std::endl;
 }
};

使う側。

1
2
3


Dog d;
d.eat();
d.bark();

Dog は Animal の機能を引き継ぐ。

ただし、C++ では継承を使いすぎると設計が複雑になりやすい。

近年は、継承よりも合成を好む設計も多い。

virtual とポリモーフィズム

C++ では virtual 関数を使うことで、実行時に呼び出す関数を切り替えられる。

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


class Animal {
public:
 virtual void speak() {
 std::cout << "..." << std::endl;
 }
};

class Dog : public Animal {
public:
 void speak() override {
 std::cout << "bow" << std::endl;
 }
};

使う側。

1
2
3


Animal* a = new Dog();
a->speak(); // Dog::speak が呼ばれる
delete a;

このように、基底クラスのポインタ経由で派生クラスの関数を呼べる。

これをポリモーフィズムという。

vtable

C++ の virtual 関数は、実装上 vtable のような仕組みで実現されることが多い。

vtable は、仮想関数の呼び出し先を管理するための表。

ただし、vtable は C++ の言語仕様上「必ずこの形で実装しなければならない」と決まっているものではない。

あくまで、多くのコンパイラで使われる実装上の仕組み。

C には virtual やクラスがないため、言語機能としての vtable はない。

ただし C でも、関数ポインタを使えば vtable のような仕組みを手動で作れる。

スマートポインタ

C++ では、手動で new / delete を直接使うより、スマートポインタを使うことが多い。

代表例。

std::unique_ptr
std::shared_ptr
std::weak_ptr

`std::unique_ptr`

所有者が1つだけのポインタ。

1
2
3


#include <memory>

std::unique_ptr<int> p = std::make_unique<int>(10);

スコープを抜けると、自動で解放される。

1
2
3


{
 auto p = std::make_unique<int>(10);
} // ここで自動解放

`std::shared_ptr`

複数箇所で所有を共有するポインタ。

1
2
3
4


#include <memory>

std::shared_ptr<int> p1 = std::make_shared<int>(10);
std::shared_ptr<int> p2 = p1;

最後の所有者が消えたタイミングで解放される。

ただし、循環参照には注意が必要。

move semantics

C++11 以降では、move semantics が重要。

ざっくり言うと、

1

重いコピーを避けて、中身を移動する仕組み

たとえば std::vector や std::string のような大きなデータを扱うとき、コピーすると重い。

move を使うと、内部データの所有権を移して効率化できる。

1
2


std::string a = "hello";
std::string b = std::move(a);

このあと、b が元の文字列データを受け取る。

a は有効なオブジェクトではあるが、中身は使わない方がよい。

`auto`

C++ では auto を使うと、型推論できる。

1
2
3


auto x = 10; // int
auto y = 1.5; // double
auto s = "hello"; // const char*

STL と組み合わせると便利。

1
2
3
4
5


std::vector<int> v = {1, 2, 3};

for (auto x : v) {
 std::cout << x << std::endl;
}

イテレータの型は長くなりがちなので、auto がよく使われる。

範囲for文

C++ では範囲for文が使える。

1
2
3
4
5


std::vector<int> v = {1, 2, 3};

for (int x : v) {
 std::cout << x << std::endl;
}

参照で受け取ることもできる。

1
2
3


for (int& x : v) {
 x *= 2;
}

変更しないなら const 参照がよく使われる。

1
2
3


for (const auto& x : v) {
 std::cout << x << std::endl;
}

`constexpr`

constexpr は、コンパイル時に計算できることを表す。

1
2
3
4
5


constexpr int square(int x) {
 return x * x;
}

constexpr int value = square(5);

この場合、value はコンパイル時に計算できる。

C++ では、実行時だけでなくコンパイル時に処理を行う仕組みが増えている。

C++ の便利さ

C++ の便利なところは、主に以下。

C に近い低レベル制御ができる
クラスでデータと処理をまとめられる
RAII によってリソース管理を自動化できる
STL によって便利なデータ構造を使える
テンプレートで汎用的なコードを書ける
const や型システムで安全性を高められる
必要ならかなり高速に書ける

C++ の難しさ

一方で、C++ はかなり難しい言語でもある。

理由は以下。

機能が多い
古い書き方と新しい書き方が混在している
ポインタ、参照、所有権の理解が必要
コンパイルエラーが長くなりがち
テンプレート周りが複雑
ABI やビルドシステムの知識も必要になる
new / delete を雑に使うと危険
未定義動作がある

そのため、現代的な C++ では、なるべく以下を使うことが多い。

std::vector
std::string
std::unique_ptr
std::shared_ptr
auto
RAII
STL アルゴリズム

逆に、できるだけ避けたいもの。

生の new / delete
不要な生ポインタ所有
手動のメモリ管理
巨大な継承階層
グローバル変数の多用

まとめ

C++ は、C をベースにしながら、より大規模で安全なプログラムを書きやすくするための機能を追加した言語。

一言でまとめると、

C++ は、Cの低レベル制御に、抽象化・型安全・リソース管理・汎用プログラミングを足した言語。

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

クラスでデータと処理をまとめる
コンストラクタで初期化する
デストラクタで後始末する
RAII でリソース管理を自動化する
参照でポインタより自然に値を渡せる
テンプレートで汎用的なコードを書ける
STL で便利なデータ構造とアルゴリズムを使える
virtual で実行時ポリモーフィズムを使える
スマートポインタでメモリ管理を安全にしやすい
move semantics で重いコピーを避けられる

C++ は覚えることが多いが、
「RAII」「STL」「所有権」「型を活かす」 を意識すると、かなり C++ らしい書き方に近づく。

Cの基本的な事

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

背景

ハードウェアに近い所のプログラミングでもCは必須
しかし、大昔にやったきりでほぼ覚えていない
そこで、改めて基本的なところからCの再学習をしたのでメモ

基本

Cの流れ

C では、プログラムは 1回で全部完成するのではなく、大きく、次の流れで作られる。

.c（と.h）コードを用意
前処理
コンパイル
アセンブル
リンク
実行

コード

`.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 は、複数ファイルのための共通の説明書ということ。

前処理

前処理とは

前処理は、C のソースコードをコンパイルする前に加工する処理。

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

1

gcc -E main.c -o main.i

`#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のソースコードをアセンブリコードに変換する処理。

各 .i / .c をそれぞれ .s にする

1

gcc -S main.c -o main.s

このとき作られる main.s は、まだ人間が読めるテキスト形式のアセンブリ。

1
2


movl $0, %eax
ret

みたいな低水準の命令になる。

つまりコンパイルは、C言語 → アセンブリとなる。

アセンブル

アセンブルは、アセンブリコードを機械語を含むオブジェクトファイルに変換する処理。

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

1

as main.s -o main.o

この main.o はバイナリ形式なので、普通にテキストエディタで読めるものではない。

つまりアセンブルは、アセンブリ → オブジェクトファイルという事。

リンク

オブジェクトファイルから、実行ファイルを作る。

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

1
2
3


main.o + add.o + sub.o + libc など
 ↓ リンク
app

疑問

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

たとえば

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 はコンパイルできる。

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

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

つまり

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

たとえば 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回だけ有効にする

ための仕組み。

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

Tool

Driver

Driver は、preprocessor / compiler / assembler / linker などを適切な順番で呼び出すツール。

代表例は gcc や g++ や clang。

たとえば、

1

gcc main.c -o app

を実行すると、gcc は内部で必要なツールを順番に呼び出して、最終的に実行ファイルを作る。

つまり gcc / clang は、日常的には compiler と呼ばれることが多いが、厳密には compiler driver としても働く。

Driver は、以下を行う。

入力ファイルの種類を判定する
preprocessor / compiler / assembler / linker を呼び出す
ライブラリやヘッダの探索パスを設定する
linker に必要な startup code や libc などを渡す

つまり、Driverはビルド全体を制御する司令塔。

Preprocessor

Preprocessor は、Cのソースコードに対して前処理を行うツール。

主に以下を処理する。

#include
#define
#ifdef
#ifndef
#if
コメント除去

たとえば、

1
2
3
4
5
6
7


#include <stdio.h>

#define MESSAGE "hello"

int main() {
 printf(MESSAGE);
}

のようなコードでは、#include によってヘッダファイルの内容が展開され、#define によってマクロが置き換えられる。

preprocess の結果だけを見たい場合は、

1

gcc -E main.c -o main.i

とする。

1
2
3


.c
 ↓ preprocessor
.i

.i は前処理済みの C ソースファイル。

1
2
3


.c
 ↓ preprocessor
.i

ソースコード → 前処理済みソースコード

を担当する。

Compiler

Compiler は、高水準言語のソースコードを、より低水準な表現へ変換するツール。

Cの場合、狭い意味での compiler は、前処理済みソースコードをアセンブリコードに変換する。

1
2
3


.i
 ↓ compiler
.s

たとえば、

1

gcc -S main.c -o main.s

とすると、C のソースコードからアセンブリファイル main.s が作られる。

.s はアセンブリファイルで、人間が読めるテキスト形式の低水準コード。

Compiler は、主に以下を行う。

構文解析
型チェック
最適化
アセンブリコード生成

つまり Compiler は、狭い意味では、前処理済みソースコード → アセンブリを担当する。

ただし日常的には、gcc / clang のような driver も含めて compiler と呼ぶことが多い。

Assembler

Assembler は、アセンブリファイルをオブジェクトファイルに変換するツール。

代表例はasコマンド。

1
2
3


.s / .S
 ↓ assembler
.o

たとえば、

1

as main.s -o main.o

とすると、アセンブリファイル main.s からオブジェクトファイル main.o が作られる。

.o は object file で、機械語を含む中間生成物。

ただし .o はまだ単体では実行できないことが多い。
外部関数やライブラリへの参照が未解決のまま残っていることがあるため。

Assembler は、アセンブリ → オブジェクトファイルを担当する。

Linker

Linker は、複数のオブジェクトファイルやライブラリを結合して、実行ファイルや共有ライブラリを作るツール。

代表例は ldコマンド。

1
2
3


.o + .o + .a/.so
 ↓ linker
実行ファイル / .so

たとえば、

1

gcc main.o foo.o -o app

とすると、main.o と foo.o がリンクされて、実行ファイル app が作られる。

Linker は、主に以下を行う。

複数の .o を結合する
未解決のシンボルを解決する
ライブラリを結びつける
実行ファイルのメモリ配置を決める
必要な startup code を含める

たとえば printf を使っている場合、コンパイル時点では printf の実体はまだ自分の .o には入っていない。
linker が libc などを探して、printf の参照を解決する。

Linker は、オブジェクトファイル + ライブラリ → 実行ファイル / 共有ライブラリを担当する。

全体の流れ

全体の流れはこう。

1
2
3
4
5
6
7
8
9


.c
 ↓ preprocessor
.i
 ↓ compiler
.s
 ↓ assembler
.o
 ↓ linker
実行ファイル / .so

より具体的には、C の場合はこう。

1
2
3
4
5
6
7
8
9


main.c
 ↓ preprocessor
main.i
 ↓ compiler
main.s
 ↓ assembler
main.o
 ↓ linker
app

役割の違い

それぞれの担当は以下。

Tool	入力	出力	役割
Driver	`.c`, `.o` など	最終成果物	全体を制御する
Preprocessor	`.c`	`.i`	`#include` や `#define` を処理する
Compiler	`.i`	`.s`	ソースコードをアセンブリに変換する
Assembler	`.s`, `.S`	`.o`	アセンブリをオブジェクトファイルに変換する
Linker	`.o`, `.a`, `.so`	実行ファイル, `.so`	オブジェクトやライブラリを結合する

Toolのまとめ

まとめると、概念的には、次の処理をまとめて行っている。

1
2
3
4
5
6


main.c → main.i → main.s → main.o
foo.c → foo.i → foo.s → foo.o

main.o + foo.o + libraries
 ↓ linker
app

役割は以下:

1
2
3
4
5


Driver = 全体を制御する
Preprocessor = #include や #define を処理する
Compiler = ソースコードをアセンブリに変換する
Assembler = アセンブリを .o に変換する
Linker = .o やライブラリをまとめて実行ファイルを作る

ファイル

`h`, `c`, `i`, `s`, `.o`, `.a`, `.so`, `a.out`

`.h`

C のヘッダファイル。

`.c`

C ソースファイル。

`.i`

.i は前処理済みの C ソースファイル。

`.s`

アセンブリファイル。 .c をコンパイルして得られる。

`.S`

プリプロセッサ付きアセンブリファイル。 #include や #ifdef などを使える。前処理されたあと as に渡されて .o になる。

`.o`

オブジェクトファイル各 .c をコンパイルした結果もしくは、sをasコマンドに渡してアセンブルすると、 .o になる。

`.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 = シンボル索引を作る

つまり

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

ということ。

GCCオプション

`-E`

-E は、前処理だけを行うオプション。

1

gcc -E main.c -o main.i

この場合、main.c に対して #include や #define などの前処理だけを行い、前処理済みソース main.i を出力する。

1
2
3


main.c
 ↓ 前処理
main.i

main.i はまだ C のソースコードに近いテキストファイル。

`-S`

-S は、アセンブリファイルまで生成するオプション。

1

gcc -S main.c -o main.s

この場合、main.c を処理して、アセンブリファイル main.s を出力する。

1
2
3
4
5


main.c
 ↓ 前処理
main.i
 ↓ コンパイル
main.s

main.s は、人間が読めるテキスト形式のアセンブリコード。

`-c`

-c は、オブジェクトファイルまで生成するオプション。

1

gcc -c main.c -o main.o

この場合、main.c から main.o を作る。
ただし、リンクは行わない。

1
2
3
4
5
6
7


main.c
 ↓ 前処理
main.i
 ↓ コンパイル
main.s
 ↓ アセンブル
main.o

複数ファイルの C プログラムでは、まず各 .c を .o にして、あとでリンクすることが多い。

1
2
3


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

`-o`

-o は、出力ファイル名を指定するオプション。

1

gcc main.c -o app

この場合、実行ファイル名は app になる。

-o を省略すると、環境によっては a.out という名前の実行ファイルが作られる。

1

gcc main.c

1

a.out

`-I`

-I は、ヘッダファイルの探索パスを追加するオプション。

たとえば、ヘッダファイルが include/ にある場合：

1
2
3
4
5


project/
 include/
 calc.h
 src/
 main.c

次のように指定する。

1

gcc -Iinclude -c src/main.c -o main.o

これにより、#include "calc.h" などを書いたときに、include/ の中も探してくれる。

1

#include "calc.h"

つまり、

1

-I = include path を追加する

ということ。

`-L`（大文字L）

-L は、ライブラリの探索パスを追加するオプション。

たとえば、現在のディレクトリに libmylib.so や libmylib.a がある場合：

1

gcc main.o -L. -lmylib -o app

ここで、

1

-L.

は、ライブラリを探す場所に現在のディレクトリ . を追加する、という意味。

つまり、

1

-L = library path を追加する

ということ。

注意点として、-L は基本的に リンク時 の探索パスを指定するもの。

実行時に .so を探す場所とは別。

`-l`（小文字L）

-l は、リンクするライブラリを指定するオプション。

1

gcc main.o -lmylib -o app

この場合、-lmylib は次のようなファイルを探す。

1
2


libmylib.so
libmylib.a

つまり、

1

-lmylib = libmylib.so または libmylib.a を探してリンクする

という意味。

lib の部分と、.so / .a の拡張子は書かない。

たとえば libm.so をリンクしたい場合は、次のように書く。

1

gcc main.o -lm -o app

これは数学ライブラリ libm をリンクする例。

`-fPIC`

-fPIC は、Position-Independent Code、つまり位置独立コードを生成するオプション。

1

gcc -fPIC -c foo.c -o foo.o

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

PIC は、簡単に言うと、

1

どのメモリアドレスに配置されても動きやすいコード

のこと。

共有ライブラリは実行時にメモリ上のどこへ読み込まれるか分からないため、PIC にしておくのが基本。

PIC とは何か

Position-Independent Code位置独立コードとは、どのメモリアドレスに置かれても動きやすいコード。

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

1
2


gcc -fPIC -c foo.c -o foo.o
gcc -shared -o libmylib.so foo.o

PICで大事なこと

PICで大事なのは以下:

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

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

`-shared`

-shared は、共有ライブラリを作るオプション。

1

gcc -shared -o libmylib.so foo.o

たとえば、共有ライブラリを作る基本形はこう。

1
2


gcc -fPIC -c foo.c -o foo.o
gcc -shared -o libmylib.so foo.o

または、1行で書くこともできる。

1

gcc -fPIC -shared -o libmylib.so foo.c

この結果、共有ライブラリ libmylib.so が作られる。

1
2
3
4
5


foo.c
 ↓ gcc -fPIC -c
foo.o
 ↓ gcc -shared
libmylib.so

GCCオプションのまとめ

オプション	役割
`-E`	前処理だけを行う
`-S`	アセンブリファイル `.s` まで生成する
`-c`	オブジェクトファイル `.o` まで生成する。リンクはしない
`-o`	出力ファイル名を指定する
`-I`	ヘッダファイルの探索パスを追加する
`-L`	ライブラリの探索パスを追加する
`-l`	リンクするライブラリを指定する
`-fPIC`	位置独立コードを生成する
`-shared`	共有ライブラリ `.so` を作る

流れで見ると、こう。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


gcc -E main.c -o main.i
 前処理だけ

gcc -S main.c -o main.s
 アセンブリまで生成

gcc -c main.c -o main.o
 オブジェクトファイルまで生成

gcc main.o -o app
 リンクして実行ファイルを生成

共有ライブラリを作る場合は、こう。

1
2


gcc -fPIC -c foo.c -o foo.o
gcc -shared -o libmylib.so foo.o

フォルダ構成

include / src / third_party

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

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

SDKのパターン

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

Makefile / CMake

Makefileの手順

昔の Cプロジェクトのビルド手順:

1
2
3


./configure # 環境チェック・Makefile 生成
make # コンパイル
make install # インストール

Configure

configure は、ビルド前に環境を調べて、Makefile を作るためのスクリプト。

主に以下をする。

コンパイラはあるか
必要なライブラリはあるか
必要なヘッダはあるか
OSやCPUアーキテクチャは何か
インストール先はどこか

そして、環境に合った Makefile を生成する。

Autoconf

configureも作る、autoconfを使った代表的な流れ:

1
2
3
4
5
6
7
8
9


開発者が書く:
configure.ac
Makefile.am

 ↓ autoconf / automake などを実行

自動生成される:
configure
Makefile.in

.ac（autoconf）,.am（automake）,.in（input）は、autoconf系のコマンドの名前。

つまり、Makefileを作るconfigureを作るのがAutoconfのconfigure.acということ。

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
)

Cmakeの実行例

基本的に、2ステップでやる。

1回目（初回のみ）：設定
2回目（コード変更のたびに）：ビルド

1
2
3
4
5
6
7
8


cmake -S . -B build \
 -DCMAKE_POLICY_VERSION_MINIMUM=3.5 \
 -DOpenCV_DIR=/usr/lib/x86_64-linux-gnu/cmake/opencv4 \
 -DCMAKE_C_COMPILER=/usr/bin/gcc \
 -DCMAKE_CXX_COMPILER=/usr/bin/g++ \
 -DCMAKE_EXE_LINKER_FLAGS="-B/usr/bin -L/usr/lib/x86_64-linux-gnu"

cmake --build build -j$(nproc)

-S . がソースディレクトリ、-B build がビルドディレクトリの指定している。

他には、次のようなパターンもよく見る。

1
2
3


mkdir build && cd build
cmake ..
cmake --build . --config Release

`CMakePresets.json`

CMakePresets.jsonは、CMake のプリセット設定。
正確には、CMakePresets.json に入れる形式の JSON で、ビルド設定を名前付きで保存しておくためのもの

プリセットを使わない場合:

1
2
3
4
5


cmake -S . -B build \
 -DCMAKE_TOOLCHAIN_FILE=... \
 -DCMAKE_SYSTEM_NAME=Android \
 -DCMAKE_ANDROID_ARCH_ABI=arm64-v8a \
 ...

使った場合:

1
2


cmake --preset linux-arm64
cmake --preset android-arm64

ABI

ABIとは

ABI は Application Binary Interface の略
日本語だとバイナリ間の取り決めくらいの意味

たとえば、

関数呼び出しのしかた
引数をレジスタに入れるかスタックに積むか
戻り値をどこに置くか
構造体のメモリ配置
シンボル名の扱い
どの形式の .so / 実行ファイルになるか

みたいなことを決める。

APIとABIの違い

API

ソースコードレベルの約束。

例:

1

int add(int a, int b);

ABI

コンパイル後の機械語レベルの約束。

同じ add(int, int) でも、ABI が違うと

引数の渡し方
関数名の見え方
呼び出し規約

が違って、リンクできなかったり実行時に壊れたりする。

また、アーキによって（例えば、x86_64 と aarch64 ）、バイナリの ABI が違うので注意。

共有ライブラリ

共有ライブラリを使うときの探索パス

共有ライブラリ .so を使う場合、注意することが2つある。

リンク時にライブラリを見つけること
実行時にライブラリを見つけること

たとえば、次のように共有ライブラリを作ったとする。

1
2


gcc -fPIC -c foo.c -o foo.o
gcc -shared -o libmylib.so foo.o

このライブラリを main.c から使って実行ファイルを作る場合は、リンク時にライブラリの場所を教える必要がある。

1

gcc main.c -L. -lmylib -o app

ここで、

-L. は、ライブラリを探す場所に現在のディレクトリを追加する指定
-lmylib は、libmylib.so または libmylib.a を探してリンクする指定

という意味。

ただし、これだけだと実行時に次のようなエラーになることがある。

1

error while loading shared libraries: libmylib.so: cannot open shared object file

これは、リンク時には libmylib.so を見つけられたが、実行時に動的リンカが libmylib.so を見つけられなかった、という意味。

このとき、一時的に共有ライブラリの場所を指定するには LD_LIBRARY_PATH を使う。

1

LD_LIBRARY_PATH=. ./app

または、先に環境変数として設定しておく。

1
2


export LD_LIBRARY_PATH=.
./app

つまり、

-L は リンク時 のライブラリ探索パス
LD_LIBRARY_PATH は 実行時 の共有ライブラリ探索パス

という違いがある。

LD_LIBRARY_PATHについて

ただし、LD_LIBRARY_PATHは絶対パスにするのがおすすめ。

xxxをコンパイルした後に、こんな感じにセットする。

1

export LD_LIBRARY_PATH="$(pwd)/xxx/build/bin${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}"

意味は、

xxxというアプリをコンパイルして、それを動かす時に、buildされた共有オブジェクトのpathを指定している
LD_LIBRARY_PATH がすでに設定されているなら、:$LD_LIBRARY_PATH を付け足す
設定されていないなら、何も付けない
:+演算子を使った${変数A:+変数A}というパラメーター展開の構文

`ldd` で共有ライブラリを確認する

実行ファイルがどの共有ライブラリに依存しているかは、ldd で確認できる。

1

ldd ./app

たとえば、libmylib.so が見つからない場合は、次のように表示されることがある。

1

libmylib.so => not found

この場合は、実行時のライブラリ探索パスに libmylib.so の場所が入っていない。

`rpath` を使う方法

LD_LIBRARY_PATH は一時的な指定には便利だが、毎回指定するのは面倒。

そこで、実行ファイルの中に共有ライブラリの探索パスを埋め込む方法もある。
これを rpath という。

たとえば、実行ファイルと同じディレクトリにある .so を探させたい場合は、次のようにする。

1

gcc main.c -L. -lmylib -Wl,-rpath,'$ORIGIN' -o app

$ORIGIN は、実行ファイル自身が置かれているディレクトリを表す。

つまりこの指定を入れると、app と同じディレクトリにある libmylib.so を実行時に探せるようになる。

共有ライブラリのまとめ

共有ライブラリ .so では、リンク時と実行時でライブラリ探索の話が分かれる。

-L はリンク時にライブラリを探す場所を指定する
-lxxx は libxxx.so や libxxx.a をリンクする指定
LD_LIBRARY_PATH は実行時に .so を探す場所を指定する
ldd で実行ファイルが依存している .so を確認できる
rpath を使うと、実行ファイル側に .so の探索パスを埋め込める

まとめ

一言でまとめると、

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

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

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

最後に超短く言うと:

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

参考文献

ld(1) - Linux manual page

C/C++ on M1KE BL0G

C++ Way

背景

C++とは

CとC++の大きな違い

C++の基本思想

クラス

struct と class の違い

コンストラクタ

デストラクタ

RAII

参照

const

関数オーバーロード

名前空間

テンプレート

STL

STLとは

コンテナ

アルゴリズム

イテレータ

例外

継承

virtual とポリモーフィズム

vtable

スマートポインタ

std::unique_ptr

std::shared_ptr

move semantics

auto

範囲for文

constexpr

C++ の便利さ

C++ の難しさ

まとめ

Cの基本的な事

背景

基本

Cの流れ

コード

.h = インターフェイス

.c = 実装

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

前処理

前処理とは

#include の意味

< > と " "

#include は前処理

前処理の例

コンパイル

アセンブル

リンク

疑問

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

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

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

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

include guard とは何か

Tool

Driver

Preprocessor

Compiler

Assembler

Linker

全体の流れ

役割の違い

Toolのまとめ

ファイル

h, c, i, s, .o, .a, .so, a.out

.h

.c

.i

.s

.S

.o

.a

.so

a.out

疑問

.a と .so の違い

`struct` と `class` の違い

`const`

`std::unique_ptr`

`std::shared_ptr`

`auto`

`constexpr`

`.h` = インターフェイス

`.c` = 実装

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

`#include` の意味

`< >` と `" "`

`#include` は前処理

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

`h`, `c`, `i`, `s`, `.o`, `.a`, `.so`, `a.out`

`.h`

`.c`

`.i`

`.s`

`.S`

`.o`

`.a`

`.so`

`a.out`

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

`ar rcs` の意味

`-E`

`-S`

`-c`

`-o`

`-I`

`-L`（大文字L）

`-l`（小文字L）

`-fPIC`

`-shared`

`CMakePresets.json`

`ldd` で共有ライブラリを確認する

`rpath` を使う方法