필사 모드: モダンC++ 2026 — C++ 23 / 26 / Modules / Reflection / Senders / std::print / CMake 3.30 / Conan 2 / vcpkg 徹底ガイド
日本語プロローグ — 「C++ は死んだ」は毎年新たに死ぬ
2010年代を通じて、C++ の死亡記事は毎年新しく書かれてきた。Go が出たとき、Rust が出たとき、Swift が出たとき、そしてZig が出たとき、毎回「次のシステムプログラミングはX が獲る」と言われ続けた。2026年5月時点で、その予測はまた外れた。C++ 23 は2024年10月にISO/IEC 14882:2024 として公式に出版され、C++ 26 は2026年のratification に向けて最後のマイルストーンを進めている。Reflection (P2996) という巨大な機能が入り、Senders/Receivers (P2300) が標準のasync モデルとして定着し、Linear Algebra (P1673) がstd に入りつつある。
同時に現場はかつてないほど忙しい。ゲームエンジン — Unreal 5.5、Unity のネイティブコア、CryEngine、内製エンジン — はいまだにC++ だ。HFT (High-Frequency Trading) のマイクロ秒単位の取引システムもC++ だ。Chromium・Firefox・WebKit などのブラウザエンジン、LLVM・GCC・Clang などのコンパイラ、MySQL・PostgreSQL・ClickHouse などのデータベース、CUDA・ROCm・oneAPI などのGPU ランタイム、すべてC++ である。サムスン・LG・ソニー・カプコン・NCsoft が作るほとんどすべてのデバイスとゲームがその上で動く。
本稿では2026年のC++ を一枚の地図として描く。標準 (C++ 23 / 26)、ビルドツール (CMake 3.30・Meson・xmake・build2・Bazel)、パッケージ (Conan 2・vcpkg)、コンパイラ (Clang 19・GCC 14・MSVC)、標準ライブラリ (libc++ vs libstdc++)、Sanitizers、そして後継言語候補 (Carbon・Hylo・Cppfront)。最後に韓国と日本の現場での使われ方で締めくくる。
1章 · 2026年のC++ — C++ 23 出版とC++ 26 仕上げ
まず全体像。
C++ 23 — 2024年10月公式出版
C++ 23 は2024年10月にISO/IEC 14882:2024 として正式に出版された。2020年のC++ 20 から3年ぶりだ。主要機能は次の通り。
- `std::expected<T, E>` — Rust の `Result` に近いモナディックなエラー処理。例外を使わないコードベースの新しいベースライン。
- `std::print` / `std::println` — `printf` とiostream の30年間の地位を獲りに行く。`{fmt}` ライブラリを標準化した結果。
- `std::generator` — コルーチンベースのlazy range。Python の `yield` パターンが標準入り。
- `std::flat_map` / `std::flat_set` — ソート済み `vector` の上に乗せたcache-friendly な連想コンテナ。
- `std::mdspan` — non-owning な多次元view。BLAS・科学計算用。
- `[[assume(expr)]]` — 最適化ヒント。
- `if consteval` — コンパイル時分岐。
- `static operator()` — ラムダの `this` キャプチャオーバーヘッドを消す。
- Deducing `this` — メンバ関数のexplicit object parameter。
C++ 26 — 2026年ratification、主役はReflection
C++ 26 は2026年にratification が終わり、ISO/IEC 14882:2026 として出版予定だ (2025年6月のSofia 会議でfeature complete が宣言された)。主要機能は以下。
- **Reflection (P2996)** — コンパイル時reflection とsplicing。C++ のmetaprogramming を一から書き換える。
- **Senders/Receivers (P2300)** — std::execution として入るasync モデル。`std::future` の後継。
- **Linear Algebra (P1673)** — BLAS 形のインターフェースを標準化。
- **Hazard pointers / RCU** — lock-free データ構造用のメモリ回収。
- **Contracts (P2900)** — 関数の事前・事後条件。C++ 20 で外され、ようやく戻ってきた。
- **Pattern matching (P2688)** — `inspect` キーワードベース。
- **`std::simd`** — データ並列型。
「なぜC++ は死なないか」 — 市場の現実
2026年時点のTIOBE やIEEE Spectrum のランキングでC++ は1~5位の間を維持し、GitHub のPR 統計でも同様だ。理由は単純である。
1. **レガシーが巨大すぎる。** Chromium・LLVM・Linux の一部・MySQL・Unreal といった巨大プロジェクトがC++ で書かれており、移行は事実上不可能だ。
2. **完全に代替できる言語がない。** Rust は素晴らしいが、すべてのC++ 領域をカバーできない (特にゲーム・科学計算・Windows GUI)。Carbon はまだalpha。Hylo は研究段階。
3. **依然として速い。** GCC 14・Clang 19 が生成するコードは世界最高峰のまま。LTO・PGO・BOLT まで合わせれば、他のコンパイル言語と同等かそれ以上。
4. **標準が生きている。** C++ 23・26 は単なる整理ではなく、**本当に新機能** が入り続けている。
2章 · C++ 23 (2024年10月出版) — std::expected / std::print / std::generator
C++ 23 で最も使われている新機能を3つ取り上げる。
std::expected — モナディックなエラー処理
Rust の `Result<T, E>` がC++ に来た。`std::expected<T, E>` は成功値T かエラー値E のどちらかを保持する。例外を使わないコードベース (ゲーム・組み込み・HFT) が長年自前で書いていたパターンが標準化された形だ。
#include <expected>
#include <string>
#include <print>
enum class ParseError { InvalidFormat, Overflow };
std::expected<int, ParseError> parse_int(std::string_view s) {
if (s.empty()) return std::unexpected(ParseError::InvalidFormat);
int v = 0;
for (char c : s) {
if (c < '0' || c > '9') return std::unexpected(ParseError::InvalidFormat);
if (v > (INT_MAX - (c - '0')) / 10) return std::unexpected(ParseError::Overflow);
v = v * 10 + (c - '0');
}
return v;
}
int main() {
auto r = parse_int("42")
.and_then([](int v) -> std::expected<int, ParseError> { return v * 2; })
.transform([](int v) { return v + 1; });
if (r) std::println("ok: {}", *r);
else std::println("err");
}
`and_then`・`transform`・`or_else` といったモナディック演算子が用意され、チェーンが自然に書ける。ゲームエンジンのasset ローダ、HFT の注文パーサ、組み込みの設定パーサが続々と移行した。
std::print / std::println — printf の後継
`{fmt}` ライブラリ (Victor Zverovich) がC++ 20 で `<format>` として入り、C++ 23 でついに出力関数 `std::print` / `std::println` まで揃った。printf のフォーマット文字列安全性とiostream のtype safety を合わせた結果だ。
#include <print>
#include <vector>
int main() {
std::println("hello {}, you are {} years old", "yj", 33);
std::vector<int> v{1, 2, 3, 4, 5};
std::println("vec = {}", v); // [1, 2, 3, 4, 5]
// 韓国語・日本語もUTF-8 でそのまま
std::println("ko: {}, ja: {}", "annyeong", "konnichiwa");
}
ベンチマーク上 `std::print` は `printf` より速く、`std::cout << ...` よりはるかに速い (locale・sync オーバーヘッドがないため)。2026年時点ではiostream は事実上deprecated 扱いの空気だ。
std::generator — コルーチンベースのlazy range
C++ 20 でコルーチンキーワード (`co_await`・`co_yield`・`co_return`) は入ったが、標準ライブラリ側のgenerator がなく、ほぼ使えなかった。C++ 23 で `std::generator<T>` が追加され、Python の `yield` パターンがC++ でも自然に書けるようになった。
#include <generator>
#include <print>
#include <ranges>
std::generator<int> fib() {
int a = 0, b = 1;
while (true) {
co_yield a;
auto t = a + b;
a = b;
b = t;
}
}
int main() {
for (int v : fib() | std::views::take(10)) {
std::println("{}", v);
}
}
Ranges と組み合わせると非常に強力だ (次章)。
3章 · C++ 26 — Reflection の時代
C++ 26 最大の事件は **Reflection (P2996)** だ。Daveed Vandevoorde・Wyatt Childers・Andrew Sutton・Faisal Vali が数年かけて磨き上げてきた静的reflection 提案がついに標準入りする。
従来のSFINAE・`<type_traits>`・マクロベースmetaprogramming を一気に置き換える可能性を持つ。中心となるのは新しい2つの演算子 `^^` と `[: ... :]`。
- `^^X` — X のreflection 値を得る (型は `std::meta::info`)。
- `[: r :]` — reflection 値r をsplice して元のentity に戻す。
#include <meta>
#include <print>
struct Person {
std::string name;
int age;
std::string email;
};
template<typename T>
void print_struct(const T& t) {
constexpr auto members = std::meta::nonstatic_data_members_of(^^T);
template for (constexpr auto m : members) {
std::println("{} = {}",
std::meta::identifier_of(m),
t.[:m:]);
}
}
int main() {
Person p{"yj", 33, "yj@example.com"};
print_struct(p);
// name = yj
// age = 33
// email = yj@example.com
}
この機能ひとつでJSON serializer、ORM、RPC stub、GUI binding、設定ローダといったライブラリが **マクロなし・boost.pfr なし・cereal なし** で短く安全に書き直される。2026年後半時点でClang trunk とEDG (Intel) が部分的に実装中。
その他のC++ 26 の大物機能。
- **`std::simd`** — SIMD が標準の型として入る。intrinsics の代わりにportable なデータ並列コード。
- **Contracts (P2900)** — `pre(expr)`・`post(expr)` で関数の事前・事後条件を表現。C++ 20 で外され、ようやく復帰。
- **Pattern matching (P2688)** — `inspect (x) { ... }` でRust の `match` に近い形。
- **Hazard pointers / RCU** — lock-free データ構造のメモリ回収技法。
4章 · Modules — ようやく実用段階か
Modules はC++ 20 で入ったが、2020~2023年はほぼ使えなかった。コンパイラ (Clang・MSVC・GCC) の実装が不完全で、ビルドツール (CMake・Bazel) との統合もひどかった。2024年から状況が急速に変わり、2026年現在は **ようやくproduction で実用に耐える**。
Modules の基本
ヘッダベース (`#include`) の問題はテキスト前処理である点だ。同じヘッダが.cpp ごとに再解析され、マクロが漏れ、ODR 違反が起き、ビルドが遅い。Modules はコンパイル済みインターフェースを一度だけ作り、各所からimport する。
// math.cppm (module interface)
export module math;
export int add(int a, int b) {
return a + b;
}
export int sub(int a, int b) {
return a - b;
}
// main.cpp
int main() {
std::println("{}", add(1, 2));
}
ビルドツール側
- **CMake 3.30 (2024年)** — C++ 20 modules のfirst-class サポート。Ninja 1.11+ が必要。
- **MSVC (Visual Studio 17.10+)** — modules が最も安定。
- **Clang 17~19** — modules ほぼ完成。`-fmodules-ts` ではなく標準の `-std=c++20` + `-fmodules`。
- **GCC 14~15** — modules 部分サポート、header units はまだ弱い。
- **Bazel** — `cc_module` rule が2025年から正式化。
効果
- ビルド時間 — Chromium の部分的なmodules 移行で、incremental ビルドが30~50% 短縮。
- ODR — module 内のマクロは外に漏れない。
- IDE — IntelliSense・clangd がmodule を理解すればnavigation が速くなる。
落とし穴
- 標準ライブラリの `import std` はコンパイラ・STL の組み合わせ次第でサポートがまだら。2026年時点でlibc++ + Clang 18+ はOK、libstdc++ + GCC 14 は部分的、MSVC STL はOK。
- ビルドシステムがmodule の依存関係を正確に計算する必要がある。`cmake --build` はmodule graph をscan してからコンパイルするので、first build はかえって遅くなることもある。
5章 · Ranges (C++ 20) — ようやく成熟
Ranges はC++ 20 で入ったが、当初はほぼ使われなかった。コンパイルエラーが恐ろしく (数十行のtemplate instantiation)、debugger 上の型が醜く、標準ライブラリ側のalgorithm が出揃っていなかったからだ。C++ 23 で欠落分が埋まり、2026年時点では日常コードの相当部分がRanges で書かれている。
#include <ranges>
#include <vector>
#include <print>
int main() {
std::vector<int> v{1, 2, 3, 4, 5, 6, 7, 8, 9, 10};
auto result = v
| std::views::filter([](int x) { return x % 2 == 0; })
| std::views::transform([](int x) { return x * x; })
| std::views::take(3);
for (int x : result) std::println("{}", x);
// 4
// 16
// 36
}
C++ 23 で追加されたもの
- `std::views::enumerate` — Python の `enumerate` 相当。
- `std::views::zip` / `zip_transform`。
- `std::views::join_with` — 文字列のjoin のように。
- `std::views::chunk` / `chunk_by` / `slide` — windowing。
- `std::views::stride` — n ステップずつ。
- `std::views::cartesian_product` — 全組み合わせ。
- `std::ranges::to<vector>` — view をcontainer にmaterialize。
auto names = std::vector<std::string>{"alice", "bob", "charlie"};
auto ages = std::vector<int>{30, 25, 40};
for (auto [name, age] : std::views::zip(names, ages)) {
std::println("{}: {}", name, age);
}
性能
Ranges はlazy なので、中間ベクタは作られない。コンパイラがinline をきちんとすれば、生成コードは手書きのfor-loop と同等になる (godbolt で確認)。ただしSTL view にはreference invalidation などの落とし穴があり、`std::ranges::to` で早めにmaterialize するのが安全なことが多い。
6章 · Senders/Receivers (P2300) — async モデル
`std::future` はC++ 11 で入ったが、ほぼ使われなかった。promise/future のコストが大きく、composition がなく、cancellation も欠け、allocator がhardcoded だったからだ。C++ 26 の **Senders/Receivers (P2300)** はこれを全部再設計する。
Eric Niebler・Lewis Baker・Kirk Shoop・Lee Howes がNVIDIA・Meta・Microsoft の実production コード (stdexec、libunifex) で磨いてきたモデルだ。
コアコンセプト
- **Sender** — 「値を非同期に生み出す」というlazy な記述。
- **Receiver** — sender の結果を受け取るsink。
- **Scheduler** — sender がどこで実行されるかを決める (thread pool、GPU stream など)。
#include <execution>
#include <print>
namespace ex = std::execution;
int main() {
auto pool = ex::static_thread_pool(4);
auto sched = pool.get_scheduler();
auto work = ex::schedule(sched)
| ex::then([] { return 42; })
| ex::then([](int x) { return x * 2; });
auto [result] = std::this_thread::sync_wait(work).value();
std::println("result = {}", result); // 84
}
なぜ重要か
従来の `std::async` はthread を直接作るか、launcher が勝手に決めるかのどちらかで、どこで実行されるかが分からない。Senders は **scheduler が明示的** なので、同じコードをthread pool・fiber・GPU stream・Linux io_uring・Windows IOCP・Android JNI thread といった様々なcontext に乗せられる。
composition も自然だ。`then`・`when_all`・`let_value`・`upon_error`・`stopped_as_optional` といったalgorithm で非同期グラフを組む。cancellation は `stop_token` で伝播する。
NVIDIA のCUDA 12・13 の一部async API はすでにsender インターフェースを露出しており、2026年後半に標準実装が登場すると見られる。
7章 · 線形代数BLAS std (C++ 26)
C++ 26 のもう一つの大物機能が **`std::linalg` (P1673)** — Bradley A. Lucier・Mark Hoemmen・Christian Trott・Daisy Hollman が主導したBLAS 形インターフェースの標準化だ。
数十年間、C++ の線形代数はEigen・Blaze・Armadillo・xtensor といった外部ライブラリに依存してきた。同じBLAS 呼び出しを毎回違うラッピングで包んだ結果、コードの可搬性が悪く、ML/AI の隆盛で標準化の遅れへの批判が高まっていた。
`<linalg>` は `std::mdspan` (C++ 23) の上にBLAS Level 1・2・3 の標準インターフェースを乗せる。
#include <linalg>
#include <mdspan>
#include <vector>
int main() {
std::vector<double> data(16);
auto A = std::mdspan(data.data(), 4, 4);
std::vector<double> x(4, 1.0);
std::vector<double> y(4, 0.0);
// y = alpha * A * x + beta * y
std::linalg::matrix_vector_product(
A, x, y);
}
裏の実装はvendor (Intel MKL、OpenBLAS、NVIDIA cuBLAS、AMD rocBLAS) が自由。標準のインターフェースだけが揃う。
ML 推論、シミュレーション、コンピュータビジョン、信号処理の分野で大きな変化を呼ぶと見られる。
8章 · CMake 3.30 / Meson / xmake / build2 / Bazel C++ — ビルドツール
C++ の永遠の悩み。2026年のビルドツール地図は次の通り。
CMake — 事実上の標準
好き嫌いに関わらずCMake は事実上の標準だ。ほぼすべてのライブラリが `find_package` または `FetchContent` で統合され、IDE (CLion・Visual Studio・Qt Creator・VS Code) もすべて対応している。
- **CMake 3.30 (2024年)** — C++ 20 modules のfirst-class サポート、presets v8、新しい `cmake -E` subcommand。
- **CMake 3.31 / 3.32** — modules サポート改善、package manifest (vcpkg / Conan 統合) 強化。
基本パターン。
cmake_minimum_required(VERSION 3.30)
project(myapp CXX)
set(CMAKE_CXX_STANDARD 23)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_CXX_EXTENSIONS OFF)
add_executable(myapp src/main.cpp)
find_package(fmt CONFIG REQUIRED)
target_link_libraries(myapp PRIVATE fmt::fmt)
CMake の欠点はよく知られている — DSL が不格好で、エラーメッセージが醜く、大規模プロジェクトではgenerator expression が複雑になる。それでも **みんなが知っている** ことが最大の強みだ。
Meson — Pythonic な代替
Meson はPython で書かれたビルドシステム。syntax が綺麗で速い。GNOME・systemd・QEMU・GStreamer が使う。CMake より速く (Ninja バックエンド標準)、subproject 管理が良い。
project('myapp', 'cpp',
default_options : ['cpp_std=c++23'])
fmt_dep = dependency('fmt')
executable('myapp', 'src/main.cpp', dependencies : fmt_dep)
欠点はCMake ほどライブラリサポートが広くないこと。ただしGNOME 圏では事実上の標準。
xmake — Lua ベースの新興
xmake は中国発のLua ベースビルドシステムで、非常に速くモダン (`xmake init` → `xmake build` → `xmake install`)。パッケージマネージャ (`xrepo`) も内蔵。ゲーム・組み込みで急速に増えている。
add_rules("mode.debug", "mode.release")
set_languages("c++23")
target("myapp")
set_kind("binary")
add_files("src/*.cpp")
add_packages("fmt")
build2 — 学術的・厳密な代替
build2 は非常に厳密で一貫したビルドシステム + パッケージマネージャ。C++ Modules サポートが最も早く正確。ユーザーは少ないが熱狂的なファンがいる。
Bazel — Google 流monorepo
Bazel はGoogle の社内ビルドシステムBlaze をオープンソース化したもの。巨大monorepo (TensorFlow、gRPC、Envoy) で輝く。hermetic build、remote cache、distributed execution が強み。欠点は学習曲線と、小規模プロジェクトには過剰なセットアップ。
BUILD.bazel
cc_binary(
name = "myapp",
srcs = ["src/main.cpp"],
copts = ["-std=c++23"],
deps = ["@fmt//:fmt"],
)
2026年時点でgoogle/bazel-cpp のmodules サポートが入った。
選定ガイド (大まかに)
- 一般オープンソース・ライブラリ → CMake
- GNOME / systemd 圏・ビルド速度重視 → Meson
- ゲーム・組み込み・中国圏・Lua フレンドリー → xmake
- Modules 完全サポート必須 → build2
- Monorepo・数万target・remote cache → Bazel
9章 · Conan 2 / vcpkg — パッケージマネージャ
数十年間、C++ の最大の弱点はパッケージマネージャの不在だった。各自がソースから直接ビルドするか、Linux distro のパッケージに依存するか、git submodule で引っ張るかだった。2020年代に2つの大選手が定着した — **Conan** と **vcpkg**。
Conan 2 (2023年メジャーリリース)
Conan はPython で書かれた分散型パッケージマネージャ。JFrog がbacking。Conan 2 は1.x から綺麗に書き直され、2026年時点では非常に安定。
conanfile.py
from conan import ConanFile
from conan.tools.cmake import CMake, cmake_layout
class MyAppRecipe(ConanFile):
settings = "os", "compiler", "build_type", "arch"
generators = "CMakeDeps", "CMakeToolchain"
def requirements(self):
self.requires("fmt/10.2.1")
self.requires("spdlog/1.13.0")
self.requires("nlohmann_json/3.11.3")
def layout(self):
cmake_layout(self)
conan install . --build=missing
cmake --preset conan-default
cmake --build --preset conan-release
Conan の強みは **profile** システム。同じパッケージを様々な設定 (debug/release、GCC/Clang、x86/arm、libc++/libstdc++) でビルドしてcache する。社内のArtifactory と連携してpatched ビルドを共有する。
vcpkg (Microsoft、2017~)
vcpkg はMicrosoft 製のマネージャ。最初はWindows 中心だったが、今ではLinux・macOS もしっかり動く。カタログが非常に大きく (3000+ ライブラリ)、CMake との統合が自然。
// vcpkg.json
{
"name": "myapp",
"version": "0.1.0",
"dependencies": [
"fmt",
"spdlog",
"nlohmann-json"
]
}
vcpkg install
cmake -B build -S . \
-DCMAKE_TOOLCHAIN_FILE=$VCPKG_ROOT/scripts/buildsystems/vcpkg.cmake
cmake --build build
vcpkg の強みはmanifest mode + binary cache。同じ依存関係を毎回再ビルドせずcache から取ってくる。Azure DevOps / GitHub Actions との統合がしっかりしている。
Conan vs vcpkg — どう選ぶか
| 基準 | Conan 2 | vcpkg |
|------|---------|-------|
| 出自 | JFrog (スペイン) | Microsoft |
| 言語 | Python recipe | CMake 風portfile |
| Profile | 非常に強力 | 弱い (triplet ベース) |
| カタログ | 1500+ | 3000+ |
| 社内cache | Artifactory フレンドリー | Azure Artifacts |
| 学習曲線 | 急 | 緩やか |
| Windows | OK | 最高 |
大まかに: **社内の多様なビルドマトリクスが必要** → Conan、**素早く始めたい / Windows メイン** → vcpkg。
10章 · Clang 19 / GCC 14 / MSVC — コンパイラ
2026年5月時点の主要コンパイラの状態。
Clang 19~20 (LLVM)
- C++ 23 ほぼ完全、C++ 26 は半分程度 (modules・reflection trunk)。
- 最速のコンパイル速度と最良の診断メッセージ。
- libc++ と最も相性が良い。
- macOS・iOS・Android (NDK) の事実上の標準。
- Apple Clang はLLVM trunk より1~2バージョン遅れる。
GCC 14~15
- C++ 23 ほぼ完全、C++ 26 も急速に追従。
- Linux サーバ・組み込みの事実上の標準。
- libstdc++ と一緒に。標準ライブラリ品質で最も信頼される。
- `-O3` のコード品質はClang よりわずかに上のことが多い (ベンチマーク次第)。
MSVC (Visual Studio 17.10+)
- Windows デスクトップ・コンソール (Xbox)・ゲーム (Unreal) の事実上の標準。
- 2010年代までC++ 標準への追従は遅かったが、今は速い。
- Modules・coroutine などで最初に実装することも多い。
- C++ 標準ライブラリ (MSVC STL) はGitHub でオープンソース (microsoft/STL)。
選定ガイド
| 環境 | 第一選択 |
|------|---------|
| Linux サーバ | GCC 14 |
| macOS / iOS | Apple Clang (またはHomebrew LLVM) |
| Windows デスクトップ / ゲーム | MSVC |
| Android NDK | Clang |
| 組み込みARM | GCC arm-none-eabi またはClang |
| HFT / 最新標準採用 | Clang trunk |
11章 · libc++ vs libstdc++ — 標準ライブラリ
C++ 標準ライブラリは事実上 **標準は一つ、実装は別** だ。2026年時点の主要実装。
- **libstdc++** — GCC 陣営。最も保守的だが完成度が高い。Linux の事実上の標準。
- **libc++** — LLVM 陣営。macOS・iOS の標準。Linux でも増加中。
- **MSVC STL** — Microsoft の標準ライブラリ。Windows の標準。GitHub でオープンソース。
違い
- ABI — libstdc++ とlibc++ は **ABI 互換ではない**。同じオブジェクトファイルを混ぜると壊れる (特に `std::string`・`std::list`)。
- 性能 — 一部アルゴリズム (例えば `std::sort`・`std::regex`) の性能が異なる。libc++ の `std::regex` の方が速いというベンチが多く、libstdc++ の `<algorithm>` の方が最適化されていることが多い。
- 標準追従 — libc++ の方が新機能の実装が一般的に速い。
- Modules — 2026年時点でlibc++ + Clang 18+ の `import std` が最も安定。libstdc++ + GCC 14 は部分的、MSVC STL はOK。
選び方
Linux でどちらを使うかはdistro と既定コンパイラに従う場合がほとんど。macOS は事実上libc++ 強制。意図的に選びたい場合はClang + `-stdlib=libc++` で。
12章 · Sanitizers — ASan / UBSan / TSan / MSan
Sanitizer はLLVM が始め、GCC が追従した、ランタイムのメモリ・同期バグ検出ツール。C++ コードの品質を一段引き上げた。
AddressSanitizer (ASan)
- 内容 — heap-buffer-overflow、use-after-free、use-after-return、double-free、leak。
- オーバーヘッド — CPU 2~3倍、メモリ 1.5~3倍。
- 使い方 — `-fsanitize=address -fno-omit-frame-pointer`。
clang++ -std=c++23 -O1 -g -fsanitize=address -fno-omit-frame-pointer main.cpp
ASAN_OPTIONS=detect_leaks=1 ./a.out
CI ですべてのテストをASan で回すのが2026年のbaseline。
UndefinedBehaviorSanitizer (UBSan)
- 内容 — signed integer overflow、null deref、divide by zero、misaligned access など。
- オーバーヘッド — ほぼなし。
- 使い方 — `-fsanitize=undefined`。
ASan と同時に使える。
ThreadSanitizer (TSan)
- 内容 — data race、一部deadlock、mutex の誤用。
- オーバーヘッド — CPU 5~15倍、メモリ 5~10倍。
- 使い方 — `-fsanitize=thread`。
マルチスレッドコードのrace 検出はほぼTSan が唯一の自動ツール。
MemorySanitizer (MSan)
- 内容 — 未初期化メモリの読み出し。
- オーバーヘッド — CPU 3倍程度。
- 注意 — 標準ライブラリまでMSan でビルドしないとfalse positive が出る (libc++ のMSan ビルドを使う)。
推奨セットアップ
- CI にASan + UBSan マトリクスを追加。
- マルチスレッドコードは別ジョブでTSan。
- nightly でfuzzer (libFuzzer + ASan) を回す。
13章 · 後継言語 — Carbon (Google) / Hylo / Cppfront (Herb Sutter)
C++ の「ABI 負担 / 安全でない既定値 / 巨大な標準」をどう解くかへの答えとして3つの大きな試みがある。
Carbon (Google、2022~)
Chandler Carruth が主導するGoogle のC++ 後継言語。核心アイデアは **双方向のinterop** — 同じコードベース内でC++ とCarbon を混ぜて使えるようにする。Swift がObjective-C の後継だったように。
package Sample api;
fn Fib(n: i32) -> i32 {
if (n < 2) { return n; }
return Fib(n - 1) + Fib(n - 2);
}
fn Main() -> i32 {
Print("fib(10) = {0}", Fib(10));
return 0;
}
2026年5月時点でCarbon はまだ0.x experimental。self-hosting もできておらず、標準ライブラリもほぼ存在せず、一般使用は推奨されない。**2030年以前にproduction で使えないというのが公式スタンス。**
Hylo (旧Val、2020~)
Dimitri Racordon・Dave Abrahams が作る研究言語。C++ の後継というより **mutable value semantics** を真剣に追求する言語。変数は既定でunique で、mutation が明示的なので、race やaliasing の問題が消える。
Swift のアイデアの一部をさらに推し進めた形。研究段階だが学界と産業界の関心を集めている。
Cppfront / cpp2 (Herb Sutter、2022~)
C++ 標準委員会のchair だったHerb Sutter が作る **「C++ の代替シンタックス」**。別言語ではなく、cppfront がcpp2 コードを受け取ってC++ にtranspile する。
// hello.cpp2
main: () = {
print("hello, world!");
}
square: (x: int) -> int = x * x;
既存のC++ と自由に混ぜて使え、安全な既定値 (default const、bounds check) を持ち込むのが核心。Carbon よりずっと軽量なアプローチ。
まとめ
2026年時点でC++ 後継言語はすべて **prototype / experimental**。今後5~10年で1, 2 個が定着する可能性はあるが、その間にC++ 自体も進化する。Reflection・Senders・Modules が入れば「C++ を離れる理由」は減る。
代替として **Rust** もますます使われている。システム・組み込み・OS 領域ではRust がC++ と直接競合する (Linux kernel のRust モジュール、Windows kernel の一部、Android の一部)。しかしゲーム・科学計算・Windows GUI・既存巨大コードベース領域では依然としてC++ が圧倒的。
14章 · 韓国 — サムスン、LG、NCsoft、Toss インフラ
韓国でのC++ 採用先を概観する。
サムスン電子
- **System LSI / Foundry** — チップ設計ツール (EDA) の一部がC++。
- **モバイル事業部** — Android のネイティブ層、カメラISP のfirmware、モデムのfirmware。
- **CE (家電)** — TV のTizen OS、冷蔵庫・洗濯機の組み込みコントローラ。
- **半導体** — メモリコントローラのverification (SystemVerilog + C++)、DRAM/NAND のfirmware。
- **Samsung Research** — AI/ML の一部、デバイス上LLM 推論エンジン。
LG 電子
- **HE (TV)** — webOS のネイティブコンポーネント、画質エンジン。
- **VS (車載)** — 車載インフォテインメント、自動運転SoC のfirmware。
- **H&A (家電)** — 洗濯機・エアコン・ロボット掃除機のコントローラ。
NCsoft
- **リネージュ・ブレイド&ソウル** — 内製エンジン (独自C++)。
- **TL (Throne and Liberty)** — Unreal Engine 5 + 独自C++。
- **AI Center** — Vapor (内製ゲームAI)、音声合成エンジン。
Toss — インフラ / トレーディング領域
- **Toss 証券 — マッチングエンジン** — 一部のlatency critical 領域でC++ を使用 (Java/Kotlin がメインだが、コアmatching の一部)。
- **インフラ — 一部ミドルウェア**。
(注: Toss のコアサービスはKotlin でC++ の比率は低いが、latency-critical 領域で使用事例がある。)
その他の韓国企業
- **カカオエンターテインメント** — ゲームサーバの一部、マルチメディア処理。
- **Krafton** — PUBG のclient (Unreal Engine 4 + 独自)、サーバサイドbattle simulator。
- **Pearl Abyss** — 黒い砂漠の自社エンジンBlackSpace (C++)。
- **Smilegate** — ロストアーク client (Unreal)、自社server engine。
- **現代自動車 / Mobis** — 車両ECU firmware、ADAS。
- **Hanwha Systems / LIG Nex1** — 防衛embedded。
韓国C++ コミュニティ
- **Modern C++ Korea** — Facebook グループ + meetup。標準委員会の韓国NB (National Body) 活動。
- **NDC (NEXON Developers Conference)** — ゲーム開発者カンファレンス。C++ track 多数。
- **書籍・翻訳書** — Chanho Ok・Sangsoo Park などのモダンC++ 書籍がよく読まれる。
15章 · 日本 — Sony PlayStation、Square Enix、Capcom、Bandai Namco
日本はゲーム・家電・自動車の本場で、ほぼすべてC++ の上で動く。
Sony Interactive Entertainment
- **PlayStation 5 / Pro / 6** — OS、SDK、devkit のほぼすべてがC++。firmware はC + C++。
- **PSN backend** — 一部C++、一部Java/Kotlin/Rust。
- **first-party スタジオ** — Naughty Dog、Insomniac、Santa Monica、Polyphony、Guerrilla — すべて自社engine またはUnreal + C++。
Square Enix
- **Crystal Tools / Luminous Engine** — FF シリーズの自社エンジン群。すべてC++。
- **ドラゴンクエスト** — Unreal Engine または自社engine。
- **外部ライセンス** — Unreal Engine 5 多数。
Capcom
- **RE Engine** — Resident Evil 7 から開始。Devil May Cry 5、Monster Hunter Rise / Wilds、Street Fighter 6 がすべてRE Engine。独自C++。
- **MT Framework (旧)** — 一部レガシー。
Bandai Namco
- **Tekken 8** — Unreal Engine 5。
- **Elden Ring — FromSoftware** — 自社engine (Souls engine)。C++。
- **ガンダムシリーズ** — Unreal または自社。
Konami
- **eFootball / ウイニングイレブン** — Unreal Engine。
- **桃太郎電鉄** — 自社。
SEGA
- **Phantasy Star Online** — 自社。
- **龍が如く / Like a Dragon** — Dragon Engine (自社C++)。
日本の自動車 (Toyota、Honda、Nissan)
- **車両ECU / Autosar** — ほぼすべてC++ またはC。Autosar Adaptive はC++ ベース。
- **ADAS / 自動運転** — C++ メイン。ROS の一部 (ROS 2 はC++)。
日本の家電 (Sony、Panasonic、Sharp)
- **TV / カメラ / オーディオ** — 組み込みLinux + C++ またはRTOS + C++。
日本のC++ コミュニティ
- **CppCon Japan / C++ MIX** — 東京・大阪のmeetup。
- **C++ 日本NB** — 標準委員会の日本representative が活発。
- **Cybozu / DeNA / GREE** — 一部backend でC++ を使用。
16章 · 誰がC++ を選ぶべきか — ゲーム / 組み込み / HFT / システム
最後に2026年の **新規プロジェクトの言語選定** でC++ を選ぶべきケースとそうでないケースをまとめる。
C++ が正解のケース
1. **ゲーム — Unreal Engine / 自社engine** — 他に選択肢がほぼない。Unreal のgameplay code もC++ (またはBlueprint)。
2. **HFT (High-Frequency Trading)** — マイクロ秒単位のlatency。JVM のGC が許されない領域。
3. **OS / システムプログラミング (一部)** — Linux kernel はC メイン + Rust 一部だが、Windows kernel の一部、Apple Darwin の一部、組み込みRTOS はC++ も多い。
4. **組み込み / firmware** — ARM Cortex-M、RISC-V、自動車ECU、家電 — C++ またはC。
5. **CAD / シミュレーション / EDA** — AutoCAD、SolidWorks、ANSYS、Synopsys、Cadence のほぼ全部。
6. **データベースエンジン** — MySQL、PostgreSQL、ClickHouse、MongoDB、RocksDB。
7. **コンパイラ / ランタイム** — LLVM、GCC、V8、JVM HotSpot 自体。
8. **グラフィックス / GPU ランタイム** — CUDA、ROCm、oneAPI、Vulkan 実装。
9. **AI 推論エンジン** — llama.cpp、PyTorch C++ runtime、TensorFlow Lite、ONNX Runtime。
Rust の方が良い可能性が高いケース
1. **新規システムプログラミング** (特にメモリ安全性が重要なもの) — Rust。
2. **WebAssembly ターゲット** — Rust の方がはるかに自然。
3. **インターネットインフラ (Cloudflare、Discord など)** — Rust が事実上の標準に。
4. **CLI ツール** — Go またはRust。
Go / Java / TypeScript が正解のケース
1. **バックエンドAPI サーバ** — Go / TypeScript / Java / Kotlin。
2. **データパイプライン** — Python / Scala / Java。
3. **GUI デスクトップアプリ** — Electron / TypeScript / C# (WPF) — ただしゲームはC++。
落とし穴
- 「安全性」が絶対要件でなければ、モダンC++ (C++ 20・23・26) の生産性も悪くない。`std::expected`・`std::print`・Ranges・Modules が日常を変える。
- 既存C++ コードベースに新機能を追加 → ほぼ常にC++ で続けるのが正解。Rust interop は可能だがABI・ビルドシステム・CI が複雑になる。
- 学習曲線 — モダンC++ は依然として急。Rust が難しいと言われるが、C++ のUB とtemplate metaprogramming ほど難しいものはない。
17章 · 結び — モダンC++ は依然として生きている
2026年のC++ は1998年のC++ でもなく、2011年のC++ でもない。C++ 23 の `std::expected`・`std::print`・`std::generator` が日常を変え、C++ 26 のReflection・Senders・Linear Algebra がライブラリ生態系を再構築する。Modules がついにビルドを軽くし、Ranges がコードを読みやすくする。
ビルドツールはCMake 3.30・Meson・xmake・build2・Bazel の中から選べ、パッケージはConan 2 とvcpkg のどちらもproduction-ready。コンパイラはClang 19・GCC 14・MSVC のすべてがC++ 23 ほぼ完成。Sanitizers が品質のbaseline になった。
後継言語 — Carbon・Hylo・Cppfront — はどれも興味深いがまだprototype。Rust は一部領域を獲ったが全部は獲れていない。ゲーム・組み込み・HFT・システム領域でC++ は依然として圧倒的で、韓国・日本の巨大企業がその上で次の製品を作っている。
「C++ は死んだ」はまた外れた。そしてその予測は今後も毎年外れ続けるだろう。その間、C++ 自体はさらに良くなっていく。
参考 / References
ISO 標準 / 委員会文書
- ISO/IEC 14882:2024 — Programming languages — C++ — [https://www.iso.org/standard/83626.html](https://www.iso.org/standard/83626.html)
- WG21 (C++ standards committee) — [https://www.open-std.org/jtc1/sc22/wg21/](https://www.open-std.org/jtc1/sc22/wg21/)
- P2300R10 — std::execution (Senders/Receivers) — [https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2300r10.html](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2300r10.html)
- P2996 — Reflection for C++26 — [https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2996r4.html](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2996r4.html)
- P1673 — A free function linear algebra interface based on the BLAS — [https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p1673r13.html](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p1673r13.html)
- P2900 — Contracts for C++ — [https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2900r6.pdf](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2900r6.pdf)
リファレンス / 学習
- cppreference — [https://en.cppreference.com/](https://en.cppreference.com/)
- Compiler Explorer (godbolt) — [https://godbolt.org/](https://godbolt.org/)
- C++ Core Guidelines — [https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines)
コンパイラ / 標準ライブラリ
- LLVM / Clang — [https://llvm.org/](https://llvm.org/)
- GCC — [https://gcc.gnu.org/](https://gcc.gnu.org/)
- MSVC STL (open source) — [https://github.com/microsoft/STL](https://github.com/microsoft/STL)
- libc++ — [https://libcxx.llvm.org/](https://libcxx.llvm.org/)
- libstdc++ — [https://gcc.gnu.org/onlinedocs/libstdc++/](https://gcc.gnu.org/onlinedocs/libstdc++/)
ビルドツール
- CMake — [https://cmake.org/](https://cmake.org/)
- Meson — [https://mesonbuild.com/](https://mesonbuild.com/)
- xmake — [https://xmake.io/](https://xmake.io/)
- build2 — [https://build2.org/](https://build2.org/)
- Bazel — [https://bazel.build/](https://bazel.build/)
パッケージマネージャ
- Conan — [https://conan.io/](https://conan.io/)
- vcpkg — [https://vcpkg.io/](https://vcpkg.io/)
Sanitizers
- AddressSanitizer — [https://clang.llvm.org/docs/AddressSanitizer.html](https://clang.llvm.org/docs/AddressSanitizer.html)
- UndefinedBehaviorSanitizer — [https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html](https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html)
- ThreadSanitizer — [https://clang.llvm.org/docs/ThreadSanitizer.html](https://clang.llvm.org/docs/ThreadSanitizer.html)
- MemorySanitizer — [https://clang.llvm.org/docs/MemorySanitizer.html](https://clang.llvm.org/docs/MemorySanitizer.html)
後継・実験言語
- Carbon — [https://github.com/carbon-language/carbon-lang](https://github.com/carbon-language/carbon-lang)
- Hylo — [https://www.hylo-lang.org/](https://www.hylo-lang.org/)
- Cppfront — [https://github.com/hsutter/cppfront](https://github.com/hsutter/cppfront)
ライブラリ / プロジェクト
- fmt (std::format / std::print の原型) — [https://github.com/fmtlib/fmt](https://github.com/fmtlib/fmt)
- stdexec (NVIDIA / Senders のreference 実装) — [https://github.com/NVIDIA/stdexec](https://github.com/NVIDIA/stdexec)
- mdspan (reference 実装) — [https://github.com/kokkos/mdspan](https://github.com/kokkos/mdspan)
韓国・日本のゲーム / エンジン
- Unreal Engine — [https://www.unrealengine.com/](https://www.unrealengine.com/)
- Capcom RE Engine — [https://www.capcom-games.com/re-engine/](https://www.capcom-games.com/re-engine/)
- NCSoft — [https://kr.ncsoft.com/](https://kr.ncsoft.com/)
현재 단락 (1/448)
2010年代を通じて、C++ の死亡記事は毎年新しく書かれてきた。Go が出たとき、Rust が出たとき、Swift が出たとき、そしてZig が出たとき、毎回「次のシステムプログラミングはX が獲る...