ディスパッチテーブルは、文字列や列挙値を関数へ結び付ける定番の仕組みです。ただしC++では、関数を追加するたびに別の登録表も更新するか、起動時にコンテナを組み立てる実装になりがちでした。

2026年8月、ISO C++ BlogでC++26の静的リフレクションを使った別の設計が紹介されました。コンパイラが対象の関数を見つけ、固定テーブルをコンパイル時に作るというものです。

では、タイトルにある「ゼロランタイムオーバーヘッド」は、検索も関数呼び出しも無料になるという意味なのでしょうか。仕組みを順にたどり、何が消えて何が残るのか、そして現時点でどこまで試せるのかを整理します。

関数名を登録表へ書き写す作業がコンパイル時の列挙に変わる

従来のディスパッチテーブルでは、if-elseの連鎖、Xマクロ、またはstd::unordered_mapのようなコンテナへ関数ポインタを登録する方法がよく使われます。いずれも動作しますが、ハンドラ本体とは別に名前と関数の対応を保守するか、実行時に登録処理を行う必要があります。

紹介されたrboxの実装記事では、対象の名前空間と命名パターンから対応表を作ります。利用側の形は次のようにかなり短くなります。

namespace ops {
int do_add(int x, int y);
int do_sub(int x, int y);
int do_mul(int x, int y);
}

constexpr auto dispatchTable = RBOX_FUNCTION_FIXED_MAP(ops, "do_*");

do_addはキー"add"、do_subはキー"sub"として関数ポインタへ結び付けられます。新しいdo_*関数を同じ名前空間へ追加すれば、別の登録リストへ同じ名前を書き足す必要はありません。

ここで減るのは「手書きの登録一覧」という重複です。マクロ、命名規則、共通の関数シグネチャ、ライブラリへの依存までなくなるわけではありません。むしろ命名規則が、どの関数を公開するか決めるコンパイル時の契約になります。

^^とstd::meta::members_ofが名前を関数ポインタへ変換する

中核にあるのは、C++26へ採択されたP2996R13の静的リフレクションです。^^opsのようなリフレクション式は、名前空間や型などを表すstd::meta::infoを生成します。

テーブルができるまでの流れは、次の5段階に分けると見通しがよくなります。

1. ^^opsで対象の名前空間をリフレクトする
2. std::meta::members_ofで直下のメンバを列挙する
3. std::meta::identifier_ofで識別子を取り出し、do_*に一致するものだけ残す
4. std::meta::type_ofで型をそろえ、std::meta::extractで関数ポインタを得る
5. キーと関数ポインタの固定表を定数評価で構築し、実行時に使える静的データとして具体化する

std::meta::infoは実行時へ持ち出すための一般的なメタデータオブジェクトではなく、定数評価のための型です。リフレクションでプログラム構造を調べる処理はコンパイル中に終わり、実行ファイルには検索に必要な固定データが残ります。

一方、members_ofが返すのは指定した名前空間やクラスの直下のメンバです。子名前空間や基底クラスまで自動で再帰するわけではなく、クラスではアクセスコンテキストも関係します。どこまでを登録対象にするかは、名前空間やクラスの構造と一緒に設計する必要があります。

ゼロになるのはテーブル構築であり、検索と間接呼び出しは残る

実行時にstd::unordered_mapへ要素を挿入する方式と比べると、固定表を組み立てる初期化処理は消せます。登録漏れを防ぎながら、起動後はコンパイル済みの表をそのまま参照できるわけです。

ただし、キーから関数を探す処理と、得られた関数ポインタを介した呼び出しは実行時に残ります。rboxの現在のREADMEでは、入力に応じて密な配列、二分探索、ハッシュテーブルを選ぶと説明されています。選ばれたデータ構造ごとの検索コストまでゼロになるわけではありません。

そのため「ゼロランタイムオーバーヘッド」は、手書き実装と比べてディスパッチ自体が無コストになるというより、登録表の発見・生成・初期化を実行時へ持ち込まない、という意味で読むのが正確です。ベンチマークを見るときも、初期化時間、1回の検索時間、バイナリサイズを分けて比べたいところですね。

また、この仕組みが列挙できるのはコンパイル時に存在する関数です。起動後にプラグインがハンドラを追加するような構成では、可変レジストリや別の動的ディスパッチ機構が引き続き必要です。固定集合に強い設計だと分かります。

2025年のC++26採択からGCC 16の実験実装へ進んだ

C++のリフレクションは突然現れた機能ではありません。P2996R13は標準化の取り組みを少なくとも2003年までさかのぼって説明しており、2025年6月のSofia会議後の編集者報告N5015でP2996R13がC++作業文書へ適用されました。

2026年4月30日に公開されたGCC 16.1は、-std=c++26 -freflectionでP2996R13を有効にできます。GCCのC++26対応表は、この対応を実験的と位置付け、最終規格との互換性を反映するために後方互換性を維持しない可能性も明記しています。

一方、Clangの公式C++対応表では、P2996R13は現時点でNoです。C++26モードを指定できることと、静的リフレクションを使えることは別なので注意が必要です。

つまり標準化上はC++26の機能になりましたが、複数の主要コンパイラで同じコードをすぐ本番運用できる段階ではありません。まずGCC 16系の実験環境で設計と生成物を評価し、採用範囲はツールチェーンの更新状況に合わせるのが現実的です。

固定されたハンドラ集合なら登録漏れとビルド制約を交換できる

この方式が合うのは、コマンド名、イベント名、演算名など、ビルド時に集合が確定するハンドラです。関数本体と登録一覧を二重管理しないため、追加時の登録漏れやキーの打ち間違いを減らせます。

一方で、採用すると次の制約を引き受けます。

• 命名パターンを公開範囲のルールとして安定させる
• 関数シグネチャの不一致をコンパイル時エラーとして扱う
• リフレクション対応コンパイラとフラグをビルド環境へ固定する
• 定数評価が広い#include経路へ拡散しないよう、テーブル定義の配置を考える

最後の点は見落としやすいところです。実装記事も、大きな定数評価が多くの翻訳単位で繰り返されるとコンパイル時間が膨らむ可能性を挙げています。ランタイムの初期化を減らしても、ビルド時間へコストを移し過ぎれば別の問題になります。

試すときは、小さな固定ハンドラ集合を1か所に定義し、従来版とリフレクション版で登録漏れの起きにくさ、コンパイル時間、検索性能、生成バイナリを比べると判断しやすいでしょう。動的登録や複数コンパイラ対応が優先なら、constexpr配列、Xマクロ、実行時コンテナを残す選択にも十分な理由があります。

C++26リフレクションは登録コードを単一の事実源へ寄せる

冒頭の問いへの答えは明確です。C++26リフレクションで消せるのは、関数と登録表を二重に書く作業と、固定表を実行時に組み立てる処理です。キー検索と間接呼び出しは残るため、ディスパッチそのものが無料になるわけではありません。

それでも、プログラム自身の名前と型をコンパイル時データとして扱い、ハンドラ定義を単一の事実源にできる意味は大きいです。現時点では実験的なツールチェーンを前提に、小さく測りながら設計上の利点を確かめる技術だと言えます。

出典

• Title: Dispatch Table with C++26 Reflection - Zero Boilerplate & Zero Runtime Overhead -- NoqtaBeda
• URL: https://isocpp.org//blog/2026/08/dispatch-table-with-cpp26-reflection-zero-boilerplate-zero-runtime-overhead