コンパイラは仮想テーブルに予約するエントリの量を認識できないため、仮想メソッドをテンプレートとして宣言できないことを理解しています。ただし、これは言語的な制限ではなく、技術的な制限です。コンパイラは、テンプレートの実際に必要なインスタンスの数を認識し、「戻って」適切な vtable サイズを割り当てることができます。
今後の規格で計画されている技術的解決策はありますか?
コンパイラは、テンプレートの可能なすべてのインスタンス化を知ることはできません。現在のコンパイル モデルでは、各翻訳単位は個別にコンパイルされ、後でリンクされます。ある翻訳単位でテンプレート型をコンパイルする場合、別の翻訳単位でのその型のインスタンス化はわかりません。
ライブラリを作成していて、その中にテンプレート関数が必要だと想像してください。ライブラリをコンパイルしてから、クライアントに配布します。これで、クライアントは好きなテンプレート引数を使用してテンプレート関数をインスタンス化できますが、ライブラリは既にコンパイルされています! 「戻って」これを変更することはできません。
テンプレート関数をコンパイルすると、その関数のすべてのインスタンス化も利用できると想定しています。多くの場合、そうではなく、現在のコンパイルおよびリンク モデルでは、そうであるとは認識できません。
既存のリンカーを使用する必要がないため、これを行うことは確かに可能です。つまり、リンカーはそのテンプレート関数のすべてのインスタンス化をふるいにかけ、適切なデータ構造を構築できます。しかし、C++ の強みの 1 つは、特殊なリンカーを必要としないことです。これにより、リンカーが石で書かれていて変更できないシステムに移植できます。そして、はい、それは起こります。リンカはすべてのオブジェクト コードが集まる場所であり、システムがサポートするすべてのプログラミング言語と互換性がなければなりません。変更は、破損の重大なリスクをもたらします。したがって、理論的には可能ですが、実現することはありません。
現在、C++ 標準委員会の論文とコア言語の問題に基づいて計画されているものはありません。C++ 標準は、C++ の実装の要件を指定しますが、技術的な実装自体は定義しません。したがって、テンプレート仮想関数は明らかに技術的な制限ではなく、標準で定義された言語の制限です。それにもかかわらず、言語の制限は、実装の技術的な制限の結果として課せられるのではなく、既存の実装の変更に伴うリスクの結果である可能性があります。