ダイナミックディスパッチ

コンピュータサイエンスにおいて、動的ディスパッチとは、実行時に呼び出す多態的操作（メソッドまたは関数）の実装を選択するプロセスです。これは、オブジェクト指向プログラミング（OOP）言語やシステムで一般的に採用されており、その主要な特徴であると考えられています。^[1]

オブジェクト指向システムは、名前で参照される操作を実行する相互作用するオブジェクトのセットとして問題をモデル化します。ポリモーフィズムとは、ある程度互換性のあるオブジェクトがそれぞれ同じ名前の操作を公開するが、動作が異なる可能性があるという現象です。たとえば、FileオブジェクトとDatabaseオブジェクトはどちらも、人事記録をストレージに書き込むために使用できるStoreRecordメソッドを持っています。それらの実装は異なります。プログラムは、 FileオブジェクトまたはDatabaseオブジェクトのいずれかである可能性のあるオブジェクトへの参照を保持します。どちらであるかは実行時設定によって決定されている可能性があり、この段階では、プログラムはどちらであるかを知らないか、気にしない可能性があります。プログラムがオブジェクトに対してStoreRecord を呼び出すと、どの動作を実行するかを選択する必要があります。OOP をオブジェクトにメッセージを送信することと考えると、この例では、プログラムは不明なタイプのオブジェクトにStoreRecordメッセージを送信し、メッセージを適切なオブジェクトにディスパッチするのは実行時サポート システムに任せます。オブジェクトは、実装した動作を実行します。^[2]

動的ディスパッチは、ポリモーフィック操作の実装がコンパイル時に選択される静的ディスパッチとは対照的です。動的ディスパッチの目的は、パラメータ（または複数のパラメータ）の実行時の型がわかるまで、適切な実装の選択を延期することです。

動的ディスパッチは、遅延バインディング(動的バインディングとも呼ばれる)とは異なります。名前バインディングは、名前を操作に関連付けます。ポリモーフィック操作には複数の実装があり、すべて同じ名前に関連付けられています。バインディングはコンパイル時または (遅延バインディングの場合は) 実行時に行うことができます。動的ディスパッチでは、操作の特定の実装が実行時に選択されます。動的ディスパッチは遅延バインディングを意味しませんが、遅延バインディングは動的ディスパッチを意味します。これは、遅延バインディング操作の実装が実行時までわからないためです。^{[引用が必要]}

どのバージョンのメソッドを呼び出すかの選択は、単一のオブジェクトまたはオブジェクトの組み合わせに基づいて行うことができます。前者はシングルディスパッチと呼ばれ、 Smalltalk、C++、Java、C#、Objective-C、Swift、JavaScript、Pythonなどの一般的なオブジェクト指向言語で直接サポートされています。これらの言語や同様の言語では、次のような構文で 除算のメソッドを呼び出すことができます。

被除数.除数(除数)   # 被除数 / 除数

ここで、パラメータはオプションです。これは、パラメータdivisor を持つ、 divideという名前のメッセージを、 dividendに送信するものと考えられます。実装は、 dividendの型 (おそらく、rational、floating point、matrix )のみに基づいて選択され、 divisorの型や値は無視されます。

対照的に、一部の言語では、オペランドの組み合わせに基づいてメソッドまたは関数をディスパッチします。除算の場合、被除数と除数の型の組み合わせによって、どの除算演算を実行するかが決まります。これは多重ディスパッチと呼ばれます。多重ディスパッチをサポートする言語の例としては、 Common Lisp、Dylan、Juliaなどがあります。

言語は、さまざまな動的ディスパッチ メカニズムを使用して実装される場合があります。言語によって提供される動的ディスパッチ メカニズムの選択によって、特定の言語内で使用できる、または最も自然に使用できるプログラミング パラダイムが大きく変わります。

通常、型付き言語では、ディスパッチ メカニズムは引数の型に基づいて実行されます (最も一般的には、メッセージの受信者の型に基づいて実行されます)。型付けシステムが弱い、または型付けシステムがない言語では、各オブジェクトのオブジェクト データの一部としてディスパッチ テーブルが保持されることがよくあります。これにより、各インスタンスが特定のメッセージを別のメソッドにマップできるため、 インスタンスの動作が可能になります。

一部の言語ではハイブリッドアプローチが提供されています。

動的ディスパッチでは常にオーバーヘッドが発生するため、一部の言語では特定のメソッドに対して静的ディスパッチを提供しています。

C++ は早期バインディングを使用し、動的ディスパッチと静的ディスパッチの両方を提供します。ディスパッチのデフォルトの形式は静的です。動的ディスパッチを取得するには、プログラマーはメソッドを仮想として宣言する必要があります。

C++ コンパイラは通常、仮想関数テーブル(vtable)と呼ばれるデータ構造を使用して動的ディスパッチを実装します。このデータ構造は、特定のクラスの名前と実装のマッピングをメンバー関数ポインターのセットとして定義します。これは、C++ 仕様では vtable について言及されていないため、純粋に実装の詳細です。そのタイプのインスタンスは、インスタンス データの一部としてこのテーブルへのポインターを格納するため、多重継承が使用される場合のシナリオが複雑になります。C++ は遅延バインディングをサポートしていないため、C++ オブジェクトの仮想テーブルは実行時に変更できず、ディスパッチ ターゲットの潜在的なセットはコンパイル時に選択された有限のセットに制限されます。

C++ では、メッセージ パラメータの型が正式なメッセージ名の一部であるとみなされるため、型のオーバーロードによって動的ディスパッチは生成されません。つまり、プログラマが見るメッセージ名は、バインディングに使用される正式な名前ではないということです。

Go、Rust、Nimでは、より汎用性の高い早期バインディングのバリエーションが使用されます。 vtableポインタは、オブジェクト参照とともに「ファットポインタ」（Goでは「インターフェース」、Rustでは「特性オブジェクト」^{[3] [4]}）として運ばれます。

これにより、サポートされているインターフェイスが基礎となるデータ構造から分離されます。コンパイルされた各ライブラリは、型を正しく使用するためにサポートされているインターフェイスの全範囲を知る必要はなく、必要な特定の vtable レイアウトだけを知る必要があります。コードは、同じデータへのさまざまなインターフェイスをさまざまな関数に渡すことができます。この汎用性は、各オブジェクト参照で余分なデータが発生することを犠牲にして実現されますが、このような参照が多数永続的に保存されている場合は問題になります。

ファット ポインタ という用語は、単に追加の関連情報を持つポインタを指します。追加情報は、前述の動的ディスパッチの vtable ポインタである場合もありますが、より一般的には、スライスなど、関連付けられたオブジェクトのサイズを表します。^{[引用が必要]}

Smalltalk は、型ベースのメッセージ ディスパッチャを使用します。各インスタンスには、定義にメソッドが含まれる単一の型があります。インスタンスがメッセージを受信すると、ディスパッチャは、その型のメッセージとメソッドのマップで対応するメソッドを検索し、そのメソッドを呼び出します。

型には基本型のチェーンが存在する可能性があるため、この検索にはコストがかかる可能性があります。 Smalltalk のメカニズムの単純な実装では、C++ よりもオーバーヘッドが大幅に高くなるように思われ、このオーバーヘッドはオブジェクトが受信するすべてのメッセージに対して発生します。

実際の Smalltalk 実装では、メソッド ディスパッチを非常に高速にするインライン キャッシング^[5]と呼ばれる手法がよく使用されます。インライン キャッシングは基本的に、呼び出しサイトの以前の宛先メソッド アドレスとオブジェクト クラス (またはマルチウェイ キャッシングの場合は複数のペア) を保存します。キャッシュされたメソッドは、メソッド セレクタに基づいて、最も一般的なターゲット メソッド (またはキャッシュ ミス ハンドラーのみ) で初期化されます。実行中にメソッド呼び出しサイトに到達すると、キャッシュ内のアドレスが呼び出されます (動的コード ジェネレーターでは、直接アドレスがキャッシュ ミス ロジックによってバックパッチされるため、この呼び出しは直接呼び出しです)。呼び出されたメソッドのプロローグ コードは、キャッシュされたクラスと実際のオブジェクト クラスを比較し、一致しない場合は、クラス内の正しいメソッドを見つけるために、実行がキャッシュ ミス ハンドラーに分岐します。高速な実装では、複数のキャッシュ エントリがある場合があり、最初のキャッシュ ミスで正しいメソッドを実行するのに数命令しかかからないことがよくあります。一般的なケースでは、キャッシュされたクラスが一致し、メソッド内で実行が続行されます。

アウトオブライン キャッシュは、オブジェクト クラスとメソッド セレクターを使用して、メソッド呼び出しロジックでも使用できます。1 つの設計では、クラスとメソッド セレクターがハッシュされ、メソッド ディスパッチ キャッシュ テーブルへのインデックスとして使用されます。

Smalltalk はリフレクション言語であるため、多くの実装では、個々のオブジェクトを動的に生成されたメソッド ルックアップ テーブルを持つオブジェクトに変更できます。これにより、オブジェクトごとにオブジェクトの動作を変更できます。プロトタイプ ベースの言語として知られる言語のカテゴリ全体がこの言語から生まれました。最も有名なのはSelfとJavaScriptです。メソッド ディスパッチ キャッシュを慎重に設計することで、プロトタイプ ベースの言語でも高性能なメソッド ディスパッチが可能になります。

Python、Ruby、Objective-C、Groovyなど、他の多くの動的型付け言語でも同様のアプローチが使用されています。

クラス Cat : 
    def  talk ( self ): 
        print ( "ニャー" )

クラス Dog : 
    def  talk ( self ): 
        print ( "Woof" )


def  talk ( pet ): 
    #動的にspeakメソッドをディスパッチします
    # petはCatまたはDogのインスタンスになります
    pet .speak ()

cat  = 猫()は
(猫)を話しますdog =犬()は(犬)を話します
  

#include <iostream> 

// Pet を抽象仮想基本クラスにする
class Pet { public : virtual void talk () = 0 ; };  

        


クラスDog : public Pet { public : void talk () override { std :: cout << "ワン！\n " ; } };     

      
    
          
    


class Cat : public Pet { public : void talk () override { std :: cout << "ニャー! \n " ; } };     

      
    
          
    


//speak() は Pet から派生したものなら何でも受け入れることができます
void talk ( Pet & pet ) { pet .speak () ; }  

    


int main () {犬fido ;猫simba ;話す( fido );話す( simba ); 0 を返す; } 

     
     
    
    
     

• ダックタイピング
• 二重派遣
• 関数のオーバーロード
• メソッドのオーバーライド
• 名前バインディング

• Lippman, Stanley B. (1996)。C ++オブジェクト モデルの内部。Addison - Wesley。ISBN 0-201-83454-5。
• Groeber, Marcus; Di Geronimo, Jr., Edward "Ed"; Paul, Matthias R. (2002-03-02) [2002-02-24]. 「RBIL62 の GEOS/NDO 情報?」.ニュースグループ: comp.os.geos.programmer. 2019-04-20 にオリジナルからアーカイブ。2019-04-20に取得。 […] Geos が16 の割り込みを必要とする理由は、コードのサイズを変更せずに、セグメント間 ("far") 関数呼び出しを割り込みに変換するスキームが使用されるためです。これを行う理由は、"何か" (カーネル) が Geos アプリケーションによって行われたすべてのセグメント間呼び出しにフックし、適切なコード セグメントが仮想メモリからロードされ、ロックダウンされるようにするためです。DOS用語で言えば、これはオーバーレイローダーに相当しますが、コンパイラやアプリケーションからの明示的なサポートを必要とせずに追加できます。次のようなことが起こります: […] 1. リアル モード コンパイラは次のような命令を生成します: CALL <segment>:<offset> -> 9A <oflow><offhigh><seglow><seghigh> ここで、<seglow><seghigh> は通常、コードが配置されているアドレスに応じてロード時に修正する必要があるアドレスとして定義されます。 […] 2. Geos リンカーはこれを別のものに変換します: INT 8xh -> CD 8x […] DB <seghigh>,<oflow>,<offhigh> […] これも 5 バイトなので、「インプレース」で修正できることに注意してください。ここで問題となるのは、割り込みには 2 バイトが必要ですが、CALL FAR 命令には 1 バイトしか必要ないことです。その結果、32 ビット ベクター (<seg><ofs>) を 24 ビットに圧縮する必要があります。 […] これは 2 つの方法で実現されます。まず、<seg> アドレスはセグメントへの「ハンドル」としてエンコードされ、その最下位ニブルは常に 0 です。これにより 4 ビットが節約されます。さらに […] 残りの 4 ビットは割り込みベクターの下位ニブルに入り、INT 80h から 8Fh までのいずれかが作成されます。 […] これらすべてのベクターの割り込みハンドラーは同じです。3.5 バイト表記からアドレスを「アンパック」し、セグメントの絶対アドレスを検索し、仮想メモリのロード処理を行った後に呼び出しを転送します。呼び出しからの戻りも、対応するロック解除コードを通過します。 […] 割り込みベクターの下位ニブル (80h～8Fh) には、セグメント ハンドルのビット 4 から 7 が保持されます。セグメント ハンドルのビット 0 から 3 は (Geos ハンドルの定義により) 常に 0 です。[…] すべての Geos API は「オーバーレイ」スキームを通じて実行されます […]: Geos アプリケーションがメモリにロードされると、ローダーはシステム ライブラリ内の関数の呼び出しを対応する INT ベースの呼び出しに自動的に置き換えます。いずれにしても、これらは一定ではなく、ライブラリのコード セグメントに割り当てられたハンドルに依存します。[…] Geosは当初、非常に早い段階で保護モードに変換することを意図していました[…]、リアルモードで「レガシー オプション」のみであるため […] アセンブリ コードのほぼすべての行がこれに対応しています […]
• Paul, Matthias R. (2002-04-11). 「Re: [fd-dev] ANNOUNCE: CuteMouse 2.0 alpha 1」. freedos-dev . 2020-02-21 にオリジナルからアーカイブ。 2020-02-21に取得。[…] このような壊れたポインターの場合 […] 何年も前に、Axel と私は、複数の割り込みベクターに対してドライバーへの *1 つの* エントリ ポイントを使用する方法 (これにより、複数のエントリ ポイントと、それらすべてでほぼ同じ起動/終了フレーミング コード用のスペースを大幅に節約できるため) を検討し、その後、内部で異なる割り込み ハンドラーに切り替えました。たとえば、1234h:0000h […] 1233h:0010h […] 1232h:0020h […] 1231h:0030h […] 1230h:0040h […] はすべてまったく同じエントリ ポイントを指します。INT 21h を 1234h:0000h に、INT 2Fh を 1233h:0010h にフックするなどすると、すべて同じ「抜け穴」を通過しますが、それでもそれらを区別して、内部で異なるハンドラーに分岐することができます。HMA ロード用のA20 スタブへの「圧縮された」エントリ ポイントを考えてみましょう。これは、プログラムがセグメント:オフセット マジックを実行しない限り機能します。[…] これを、複数のエントリポイントを持つ反対のアプローチ ( IBMの割り込み共有プロトコルをサポートする場合もあります) と比較してください。このアプローチでは、多くの割り込みをフックすると、はるかに多くのメモリが消費されます。 […] 他のドライバーが何らかの理由でポインターを正規化または非正規化するかどうかはわからないため、これは実際にはおそらく安全ではないという結論に達しました。[…](注: これは、 x86プロセッサ上のIntelのリアルモードセグメント:オフセット アドレス指定専用の「ファット ポインタ」に似たもので、共有コード エントリ ポイントへの意図的に非正規化されたポインタと、共有コード内の異なる呼び出し元を区別するための情報の両方が含まれています。オープン システムでは、ポインタ正規化サード パーティ インスタンス (他のドライバーまたはアプリケーション内) をパブリック インターフェイスで完全に排除することはできませんが、このスキームは、冗長なエントリ コード シーケンスを回避するために内部インターフェイスで安全に使用できます。)
• Bright, Walter (2009-12-22). 「C の最大の過ち」. Digital Mars . 2022-06-08 にオリジナルからアーカイブ。2022-07-11に取得。[1]
• Holden, Daniel (2015). 「A Fat Pointer Library」. Cello: High Level C . 2022-07-11 にオリジナルからアーカイブ。2022-07-11に取得。