MFC は、効率的な方法を使用して、仮想関数に関連するスペース消費と複雑さの問題に対処します。たとえば、以下の画像は、クラス階層内の関数がどのようにフェッチされるかを示しています。この実装は、スペース効率が高く、理解しやすく、効率的でもあるようです。
私の質問は、コア C++ が同じ方法を使用してコンパイラの複雑さを軽減し、vtables を削除しないのはなぜですか? おそらく、この実装にも効率の問題がありますか?
MFC は、効率的な方法を使用して、仮想関数に関連するスペース消費と複雑さの問題に対処します。たとえば、以下の画像は、クラス階層内の関数がどのようにフェッチされるかを示しています。この実装は、スペース効率が高く、理解しやすく、効率的でもあるようです。
私の質問は、コア C++ が同じ方法を使用してコンパイラの複雑さを軽減し、vtables を削除しないのはなぜですか? おそらく、この実装にも効率の問題がありますか?
C++ ポリモーフィズムは、すべてのコンパイラで多かれ少なかれ同じように実装されています。messageEntries
各オブジェクトには、実際の関数アドレスを取得するために逆参照されるvtable ( に相当) があります。
C++ ポリモーフィズムは、マクロやその他の操作を必要としないため、MFCよりも優れています。唯一の変更点はvirtual
キーワードで、残りのコードは同じままです。
使いやすさはどうですか?
// Compare
object_ref._messageEntries[WM_PAINT](); // MFC
// vs.
object_ref.paint(); // C++
効率に関しては、仮想メソッドは別のポインター逆参照を追加しますが、これは理論的には回避できます。パフォーマンスが重要なコードを記述する場合、実行される操作の数を減らして、実行時のポリモーフィズムをすべてダンプする必要があります。ただし、組み込み言語ソリューションは確かに MFC よりも遅くはありません。
MFC のソリューションのプロは、イベントをディスパッチするときに表示されます。この場合、インデックス可能な関数配列を使用すると、コンポーネントを介したイベントの受け渡しが容易になるため、大きなプラスになります。
MFC クラスを詳しく調べると、多くの仮想メソッドが表示されます。上の図に表示されているのは、多くの GUI フレームワークで使用されているメッセージ駆動型のメカニズムです。Android で使用されているような新しいフレームワークでも使用されています。
メッセージ駆動型通信の主な目的は、GUI 関連のすべての処理が GUI スレッドで行われるようにすることです。また、すべてのメッセージがキューに入れられるため、一定の順序で管理されます。これは実際には、C++ がどのように設計されたか、または設計されるべきかとは何の関係もありません。
仮想メソッドを使用しないフレームワークを調べたい場合は、WTL/ATL と CRTP を調べてください。
http://en.wikipedia.org/wiki/Curiously_recurring_template_pattern