仮想関数の「見えないコスト」をゼロに：C++の脱仮想化と静的多態性の全貌

はじめに：クリーンな設計が遅い理由
What：仮想関数の「見えないコスト」とは何か
1. 仮想ディスパッチの仕組み
2. アセンブリで見る違い
How：コンパイラの脱仮想化（Devirtualization）
How：静的多態性（Static Polymorphism）
1. CRTP：奇妙な再帰テンプレートパターン
2. C++23の「Deducing this」
When：いつ静的多態性を使うべきか
Why：なぜこれが重要なのか
1. モダンC++のパラダイムシフト
2. 実世界の影響
実践的なガイドライン
まとめ
参考資料
📚 関連記事
📚 AI学習におすすめの資料

はじめに：クリーンな設計が遅い理由

「オブジェクト指向設計は完璧なはずなのに、ベンチマークで遅い」——そんな経験はないだろうか。

C++で多態性（ポリモーフィズム）を実現する仮想関数は、美しい抽象化を提供するが、その裏には「見えないコスト」が隠されている。ポインタの間接参照、オブジェクトサイズの増加、インライン化の阻害……これらは積み重なると無視できないオーバーヘッドになる。

2026年2月、Redditのr/programmingで注目を集めた記事「Devirtualization and Static Polymorphism」は、この問題に深く切り込んでいる。本記事では、仮想関数の隠れたコストと、コンパイラがそれをどう最適化するか、そして開発者が手動で回避する手法までを詳しく解説する。

What：仮想関数の「見えないコスト」とは何か

仮想ディスパッチの仕組み

C++でvirtualキーワードを使うと、コンパイラは裏で次のような仕組みを構築する：

仮想テーブル（vtable）：各クラスごとに作成される関数ポインタのテーブル
仮想ポインタ（vptr）：各オブジェクトに追加される、vtableへのポインタ

┌─────────────┐
│   Base      │
│  ┌───────┐  │     ┌──────────────┐
│  │ vptr  │──┼────▶│ Base vtable  │
│  └───────┘  │     │ ┌──────────┐ │
│  data...    │     │ │ foo()    │ │
└─────────────┘     │ └──────────┘ │
                    └──────────────┘

仮想関数を呼び出す際、コンパイラは：

vptrをロード
vtableから適切なスロットを選択
その関数ポインタ経由で間接呼び出し

この「間接呼び出し」こそが、パフォーマンスの敵だ。

アセンブリで見る違い

非仮想関数の場合：

bar(Base*):
    sub rsp, 8
    call Base::foo()      ; 直接呼び出し
    add rsp, 8
    add eax, 77
    ret

仮想関数の場合：

bar(Base*):
    sub rsp, 8
    mov rax, QWORD PTR [rdi]    ; vptrをロード
    call [QWORD PTR [rax]]      ; 間接呼び出し
    add rsp, 8
    add eax, 77
    ret

違いは明確だ。仮想呼び出しは：

メモリアクセスが増える（vptr、vtable）
分岐予測が困難（呼び出し先が実行時まで不明）
インライン化が不可能（関数本体が不明）

How：コンパイラの脱仮想化（Devirtualization）

コンパイラが最適化できるケース

コンパイラは賢い。静的に呼び出し先を特定できる場合、自動的に「脱仮想化」を行う：

struct Base {
    virtual auto foo() -> int = 0;
};

struct Derived : Base {
    auto foo() -> int override { return 77; }
};

auto bar() -> int {
    Derived derived;
    return derived.foo();  // Derived::foo()と確定
}

この場合、コンパイラはderivedの動的型がDerivedであることを静的に証明できる。したがって、直接呼び出し（またはインライン化）が可能だ。

コンパイラフラグによる強化

翻訳単位（TU）をまたぐと、コンパイラの推論は困難になる。そこで役立つのがコンパイラフラグだ：

フラグ	効果
`-fwhole-program`	このTUがプログラム全体であると仮定
`-flto`	リンク時最適化（LTO）で複数TUを統合最適化

finalキーワードの活用

C++11以降、finalキーワードで「これ以上派生しない」ことをコンパイラに伝えられる：

class Derived : public Base {
public:
    auto foo() -> int override;     // まだオーバーライド可能
    auto bar() -> int final;        // これ以上派生不可
};

auto test(Derived* derived) -> int {
    return derived->foo() + derived->bar();
}

生成されるアセンブリ：

test(Derived*):
    push rbx
    sub rsp, 16
    mov rax, QWORD PTR [rdi]
    mov QWORD PTR [rsp+8], rdi
    call [QWORD PTR [rax]]      ; foo()は仮想呼び出し
    mov rdi, QWORD PTR [rsp+8]
    mov ebx, eax
    call Derived::bar()         ; bar()は直接呼び出し！
    add rsp, 16
    add eax, ebx
    pop rbx
    ret

bar()は直接呼び出しに変換されている。

How：静的多態性（Static Polymorphism）

CRTP：奇妙な再帰テンプレートパターン

コンパイラが脱仮想化できない場合、手動で「静的多態性」に置き換えられる。その代表的な手法がCRTP（Curiously Recurring Template Pattern）だ：

template <typename Derived>
class Base {
public:
    auto foo() -> int {
        return 77 + static_cast<Derived*>(this)->bar();
    }
};

class Derived : public Base<Derived> {
public:
    auto bar() -> int {
        return 88;
    }
};

auto test() -> int {
    Derived derived;
    return derived.foo();
}

最適化後のアセンブリ：

test():
    mov eax, 165    ; 77 + 88、完全に定数畳み込み！
    ret

vtableもvptrも間接参照もない。すべてコンパイル時に解決され、インライン化と定数畳み込みが適用される。

C++23の「Deducing this」

C++23では、より簡潔な記法が導入された：

class Base {
public:
    auto foo(this auto&& self) -> int { 
        return 77 + self.bar(); 
    }
};

class Derived : public Base {
public:
    auto bar() -> int { return 88; }
};

this auto&&を使うと、テンプレートクラスにする必要がなくなる。コンパイラがselfの型を推論し、静的にディスパッチする。

When：いつ静的多態性を使うべきか

適用すべきケース

レイテンシ重視のパス：高周波取引、ゲームエンジンのコアループ
テンプレートライブラリ：STLのイテレータのような設計
コンパイル時に型が確定：実行時の柔軟性が不要な場合

避けるべきケース

実行時の動的ロード：プラグインシステム
異種コンテナ：std::vector<std::unique_ptr<Base>>
バイナリサイズ制約：テンプレートのインスタンス化はコードサイズを増やす

トレードオフの理解

動的多態性	静的多態性
実行時の柔軟性	コンパイル時の性能
異種コンテナ可能	型ごとに異なる型
vtableのオーバーヘッド	ゼロオーバーヘッド抽象
コードサイズ小	テンプレート肥大化の可能性
デバッグ容易	コンパイルエラーが複雑