質問への回答
質問の歴史
C++23 以前は、静的ポリモーフィズムを実装するには奇妙な再帰テンプレートパターン (CRTP) が必要でした。このアプローチは、派生クラスが自身の派生型でインスタンス化された基本クラステンプレートを相続することを強制しました。機能的ではあるものの、CRTP は冗長なコードと、保守が困難な複雑な継承階層を生じさせました。
問題
根本的な問題は、CRTP 基底におけるメンバ関数が、明示的なテンプレートパラメータなしでは実際の派生型を推測できなかったことです。この制限により、開発者は手動で this を派生型にキャストしなければならず、継承チェーンが変更されると壊れる脆弱なコードが生じました。さらに、CRTP により、容易なリファクタリングが妨げられ、テンプレートメタプログラミングに不慣れなユーザーにとってインターフェースが直感的ではなくなりました。
解決策
C++23 では、明示的オブジェクトパラメータ (推測された this) が導入され、メンバ関数が this を推測型の明示的なパラメータとして宣言できるようになりました。 void func(this auto&& self) と書くことで、関数は任意のオブジェクト型を受け入れ、継承ではなくオーバーロードを通じて静的ポリモーフィズムを実現できます。このアプローチは CRTP を完全に排除し、オープンポリモーフィズムをサポートするクリーンなコードを生成します。
// C++23 のアプローチ struct Vector { float x, y; template<typename Self> auto magnitude(this Self&& self) { return std::sqrt(self.x * self.x + self.y * self.y); } }; // 継承なしで使用可能 Vector v{3.0f, 4.0f}; float len = v.magnitude();
実生活の状況
ゲームエンジンチームは、CPU と GPU コンパイルパスの両方をサポートする数学的なベクトルライブラリを必要としていました。このライブラリは、ゼロオーバーヘッド抽象化を維持しながら、float、double、および half 精度型で動作する magnitude() や normalize() などの汎用操作が必要でした。
最初に考えられたアプローチは、基本クラス VectorBase<Derived, T> を持つ CRTP でした。これはコンパイル時ポリモーフィズムを許可しましたが、複雑さを増しました。新しいベクトル型が追加されるたびに基本から相続し、自身をテンプレートパラメータとして渡さなければならず、冗長なコードとリファクタリング中の暗号的なテンプレートインスタンス生成エラーを引き起こしました。基本インターフェースを変更すると、すべての派生クラスの更新が必要になるため、保守は困難でした。
次に考えられたアプローチは、自由関数とタグディスパッチングを使用した関数オーバーロードでした。これにより継承を回避できましたが、グラフィックチームが好むオブジェクト指向設計が崩れました。数学的オブジェクトに対してメソッドを呼び出す代わりにベクトルインスタンスをパラメータとして渡す必要があり、不自然でした。さらに、API サーフェスが複雑になり、メソッドチェイニングが不可能になりました。
選ばれた解決策は、C++23 の明示的オブジェクトパラメータ構文でした。チームはベクトルクラスを auto&& self パラメータを使用するように書き直し、継承なしで静的ポリモーフィズムを可能にしました。このアプローチは、直感的な vec.magnitude() 構文を維持しながら、汎用プログラミングをサポートし、テンプレートの冗長性を排除しました。
その結果、テンプレート関連のコンパイルエラーが40%減少し、開発者の生産性が向上しました。コードベースは大幅に保守性が向上し、メソッドチェイニングはすべてのベクトル型でシームレスに動作しました。チームは CRTP の複雑さなしにライブラリを CPU と GPU ターゲットの両方に正常に展開しました。
候補者が見落としがちな点
メンバ関数が const と宣言されているが推定された型が const 修飾されていない場合、明示的オブジェクトパラメータの推定は失敗します。なぜですか？
候補者は、this auto&& self を使用すると、推定された型には式の cv 修飾子が含まれることを見落としがちです。関数が const オブジェクトで呼び出されると、型は自動的に const T& になります。
ただし、候補者が const オブジェクト上でパラメータを this T self (値渡し) と間違えて宣言すると、コピーを試みます。これにより、削除されたコピーコンストラクタや高コストの深いコピー操作が発生する可能性があります。
重要なインサイトは、auto&& が参照の崩壊規則に従い、constness を自動的に保持することです。これは、明示的修飾なしで const 正しさを確保するための好ましい形式です。
明示的オブジェクトパラメータは、std::function オーバーヘッドなしで再帰的ラムダパターンを可能にするのはどのようにしてですか？
候補者は、明示的オブジェクトパラメータにより、ラムダが自分自身を呼び出せるようになるが、std::function タイプ消去がないことを見落としがちです。ラムダを自分自身を受け入れる明示的な auto パラメータで宣言することで、そのパラメータを使用して再帰することができます。
例えば、auto factorial = [](this auto&& self, int n) -> int { return n <= 1 ? 1 : n * self(n-1); }; は、オーバーヘッドゼロの再帰ラムダを生成します。コンパイラはコンパイル時に正確な型を知っているため、完全なインライン化と最適化が可能です。
この機能がなければ、再帰には std::function が必要となり、タイプ消去オーバーヘッドが生じ、インライン化ができなくなります。別の選択肢として、開発者は意図を隠す複雑な構文の固定点合成器を使用しました。
明示的オブジェクトパラメータは、完全な型保持で直接の自己参照を提供します。このパターンは、性能を維持しながら、汎用コードにおけるエレガントな再帰アルゴリズムをサポートします。
明示的オブジェクトパラメータを使用すると、従来のクラス階層の形成がどのように防止される一方で、ポリモーフィックな振る舞いがどのように可能になりますか？
この微妙な点は多くの候補者を混乱させます。従来のポリモーフィズムは継承と仮想関数に依存し、基本クラスと派生クラス間の密接な結合をヴァーチャルテーブルを介して作成します。
明示的オブジェクトパラメータは「オープンポリモーフィズム」を可能にし、必要なインターフェースを提供する任意の型が関数を使用できるようになります。共通の基底クラスから相続することや仮想デストラクタの必要はありません。
重要な違いは、明示的オブジェクトパラメータを使用することでポリモーフィズムがコンパイル時にオーバーロード解決を通じて解決される点です。キャストする基本クラス型がないため、オブジェクトスライスを防ぎ、ヴァーチャルテーブルオーバーヘッドを排除します。
ただし、これは、タイプ消去なしに基本クラスポインタのコンテナに異種オブジェクトを格納できないことも意味します。ポリモーフィズムは厳密に静的であり、性能の利点を提供しますが、動的ポリモーフィズムとは異なるアーキテクチャ上の制約を与えます。