おそらく、多くのC ++プログラマーがマルチメソッドについて聞いたことがあり、今日までこの言語の受け入れ可能な実装がないことを知っています。言語サポートも外部ライブラリもありません。 コードジェネレーター、仮想メソッドを使用したトリック、デュアルディスパッチの特別なケース、つまり訪問者パターンがあります。 ただし、いくつかの関数を実装して、次のことを示すだけです。この関数セット-マルチメソッドとポイントがあります。



MeyersとAlexandrescuは長い間、マルチメソッドとライブラリ実装のいくつかのアプローチについて書いてきました。 ほぼ20年間、これらのアイデアはC ++に関するさまざまな文献で議論されてきましたが、これまでのところ、実際のプロジェクトで便利に使用できる完全なソリューションまで開発されていません...



私は運を試し、あえてこの問題に対する私のビジョンとそれを解決する方法を提供することにしました。 その結果、ヘッダーのみのテンプレートライブラリが作成されました。

これは、純粋なC ++でのC ++ 03標準の下での実装です。コードジェネレーターや追加はありません。 目標は、実行時にタイプ（および値によっても）で関数をオーバーロードする機能を実現するためのシンプルで直感的なインターフェイスを備えたライブラリです（最小限のプログラムでした。



テストドライブの場合は、 ソースをダウンロードし、＃includeをいくつか作成する必要があります。



プレゼンテーションは単純なものから複雑なものまで選択しました。 したがって、この記事では、ライブラリを使用する最も簡単な方法について説明しますが、これまでのところ、実装手法については説明しません。

マルチメソッドとは何ですか？

同義語がいくつかあります：複数のディスパッチ、タイプによる複数の切り替え、実行時の関数のオーバーロード。 このトピックに関する多くの情報がインターネットと文献にあります。したがって、私は同じことをクロスポストしませんが、いくつかのリンクを提供します。

英語とロシア語のウィキペディア。

C ++でマルチメソッドを使用する理由

この問題も開示しません。

私はすぐに、目標がマルチメソッドを実装する試みであり、C ++で必要かどうかを正当化する抽象的な推論ではないことをお知らせします。 誰かが必要としますが、誰かは必要としません。 イディオムがある場合、誰かがそれを好きかどうかに関係なく、実装には存在する権利があります。 他の言語にはそのような実装があるため、言語またはライブラリの一部で、なぜC ++が悪いのですか？

ところで、C ++はいつか言語側からのマルチメソッドをサポートするかもしれません。 BjörnStraustrupのオファーです 。 以前は、誰もがC ++ 0xエディションに登場することを期待していましたが、これまでのところ、この提案は適切に解決されていません。



自分から追加できます。 Straustrupは、可能であれば、内部メンバーメソッドの代わりに、そのような関数がクラスのパブリックインターフェイスに十分な場合、その関数を優先することをお勧めします。 しかし、関数が多相引数を処理する必要がある場合はどうでしょうか？ 階層全体（またはその一部）に浸透する新しい仮想メソッドを追加する必要があるたび。 これは、データとメソッドの緊密な接続の機能です。 マルチメソッドを使用すると、この依存関係を回避でき、クラス階層に干渉することなく機能を拡張できます。 つまり、内部仮想メソッドを使用せずに、外部仮想メソッドを作成できます。1つからではなく、複数の多態的な引数から作成できます。 一般的に、アプリケーション部分は非常に広いです。

ちょっとした歴史

2009年に、C ++と設計手法を研究する過程で、「Gangs of Four」、 「Methods of Object-Oriented Design 」という本から初めてマルチメソッドについて学びました。 デザインパターン。「訪問者」セクション。 そのとき、C ++のマルチメソッドの実装を使用することに関して健全で単純なものはないというのは、私にとって奇妙に思えました。 プロトタイプをスケッチし、趣味として自由時間に開発しました（ほぼ完全に数回書き直しました）。 Alexandrescuを読むと、彼は複数の方法でマルチメソッドを実装していることがわかりました。 しかし、それらは非常に限定的で使用が困難であることが判明し、場合によってはまったく機能しません。これは彼の本のメタプログラミングの例にすぎません。 また、接頭辞「multi」は無意味です。その実装は、2つの引数の関数に対してのみ機能します。 さらにいくつかのタイプの実装を見つけましたが、スケジューリングをサポートするためにコードジェネレーターまたは手動コードの作成と階層の大幅な変更が必要でした。 これはすべて非常に複雑であるため、C ++でマルチメソッドを使用する必要はありません。 インターフェイスを非常に単純な形式で提示し、パフォーマンスが許容できる実装を提供することで、これらの問題を取り除く方法を見つけることができました。 今後、マルチメソッドを作成する最も簡単な方法の1つ（およびライブラリには、アルゴリズムの動作に関する既製のポリシーまたは独自のポリシーを使用して、単純なものから手動で微調整する方法まで、多くの方法が用意されています）：

mml::make_multimethod(f1, f2,..., fn)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

f1、f2、...、fnは、動的にリロードする（つまり、それらからマルチメソッドをアセンブルする）必要がある関数または呼び出し可能オブジェクトの名前です。 引数に追加の要件はありません。make_multimethodは、デフォルトパラメータで設定されたマルチメソッド（動的にオーバーロードされた関数）を表す関数オブジェクトを返します。 これは、ライブラリユーザーを入力するための低いしきい値であり、追加の知識は必要ありません。

結果として、おそらくまともなライブラリーが形成されました。私はそれをtrite： MML-MultiMethod Libraryと呼びました。 彼女が光を見る時が来ました。おそらく、彼女は誰かに役立つでしょう。 ほぼ3年間にわたって、C ++でのマルチメソッドの状況はどこにも移動していません（私見、私は何かを知らないだけかもしれません）。

問題の声明

マルチメソッドがすべきことは理解できます。 しかし、彼はそれをどのように行う必要があり、そして重要なことに、それはどのように見えるのでしょうか？ 主な目的、つまり実行時のオーバーロードを基に構築します 。 オブジェクト指向のオーバーロードとは何ですか？ 一般的に、C ++でのコンパイル中の関数のオーバーロードはどのように見えますか？ 分析しましょう。

オーバーロードルールの詳細（継承、使用宣言、Koenigの検索など）をすべて説明することなく、簡単な例を考えてみましょう。

 void f(int){} void f(double){} void f(char, void*){}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

関数名fは、引数のタイプとその数によって3回オーバーロードされることがわかります。 関数のオーバーロードはO ++の利点としてC ++に登場したという事実（Cにはオーバーロードはありません）にもかかわらず、その形式はオブジェクト指向のような匂いはしません。 これら3つの関数は暗黙的に接続されています。さらに、名前の一致により、「オーバーロードされた関数」という用語は全体としてこの例には当てはまりません。 たとえば、このセットを変数に完全に保存するか、何らかの関数に渡して、後でオーバーロードを使用して呼び出しを行います。

 auto of = f; //      f
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この言語には、オーバーロードされた関数のセットを単一のオブジェクトに結合する手段がありません。 この形式のオーバーロードはカプセル化を拒否します。

オブジェクト指向の代替案を検討してください。

 struct f { void operator()(int) const {} void operator()(double) const {} void operator()(char, void*) const {} }; auto of = f(); //  , of  ,      
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

すべての関数がファンクター（関数オブジェクト）としてより良く設計されたと思うかもしれません。 これは、たとえば、すべてのタスクに対してではなく、標準アルゴリズムなどに述語を渡すときにインライン化の利点を得るために正当化される場合の常識です。 通常の古き良き関数ではなく、ファンクターの不当なスペルは、不便で時間がかかり、一部のタスクでは受け入れられない解決策にもなります。



そのため、オブジェクト指向のスタイルでは、オーバーロードされた関数は、演算子（）がオーバーロードされたファンクター（関数型オブジェクト）です。 MMLライブラリには、多くの個別の呼び出し可能エンティティ（これらはファンクタ、ラムダ、および通常の関数へのポインタ）をラップし、それぞれに対してオーバーロードされたoperator（）を表す既製の便利なテンプレートがあります。 これはオブジェクトoverloaded_function <F1、... Fn>と関数make_overloaded_function（f1、...、fn）であり、引数の型を介してテンプレートのパラメーターを表示してオブジェクトを作成します。



overloaded_functionは、コンパイル時に演算子（）を使用して呼び出すことができるオーバーロード関数であるエンティティです。 同じ理由で、マルチメソッドインターフェイスを設計するときは先に進む必要があります。 つまり 外部的にはオーバーロードされたファンクタのように見える呼び出し可能なエンティティである必要がありますが、コンパイル時に不明な実際の動的な型のパラメータに応じて実行時にオーバーロードを実行します。 マルチメソッドはオブジェクト値である必要があり、それ自体に必要なすべてのデータが含まれている必要があります。 Assignableの概念をサポートします。 このようなインターフェースと動作により、マルチメソッドは通常の呼び出されたエンティティのように見え、STL、ブースト、および特別な適応なしで多くのSTL類似ライブラリおよびユーザーコードと対話できます。



合計 次の問題のステートメントを取得します：静的に（コンパイル時に）オーバーロードされた関数のセットを含む呼び出し可能なエンティティを開発し、呼び出し可能なインターフェイスを提供し、実行時にセットから目的の静的関数に着信呼び出しをディスパッチします。

提案されたソリューション

マルチメソッド自体に加えて、問題に対する最も一般的なソリューションのためのクラス、戦略、特性のクラス、ファサード、アダプター、およびその他のユーティリティのセットを取得することができました。 しかし、なぜなら 入門記事では、今のところ、マルチメソッドを使用する最も簡単な方法、いわゆる低しきい値について説明します。 これを行うために、ターゲットの呼び出し可能エンティティmake_multimethodのセットに基づいてマルチメソッドファサードとそれを作成する関数を準備しました 。 ライブラリのコアはディスパッチャテンプレートクラスです。詳細については次の記事で説明します。これは最大限に一般化されており、マルチメソッドの実装のみに限定されません。マルチメソッドはディスパッチャの使用を簡素化するファサードです。



おそらく十分な理由があるので、コメント付きの例を使用して、それがいかに単純かを理解することをお勧めします。



たとえば、単純な階層が必要です。 私は古典的な例を使用します：宇宙船、小惑星、宇宙ステーションを衝突させるゲーム：





便宜上、ゲームオブジェクトへのポリモーフィックポインターの配列を返す関数：





ターゲットの静的にオーバーロードされた関数のセット：

 const char* collide_go_go(game_object*, game_object*) { return "Unsupported colliding!"; } const char* collide_sh_sh(space_ship*, space_ship*) { return "Space ship collides with space ship"; } const char* collide_sh_as(space_ship*, asteroid*) { return "Space ship collides with asteroid"; } const char* collide_as_sh(asteroid*, space_ship*) { return "Asteroid collides with space ship"; } const char* collide_as_as(asteroid*, asteroid*) { return "Asteroid collides with asteroid"; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

オーバーロードされているものは、あなたが尋ねる、彼らは異なる名前を持っています。 はい、住所を取得するための便宜のために異なります。 誰かが本当に必要な場合は、同じ名前を付けることができます。関数のアドレスを取得するときに、あいまいさを解決する必要があります。



最初の重要なポイント。 マルチメソッドを作成します（ヘッダー<mml / generation / make_multimethod.hpp>を接続する必要があります）：

 #include <mml/generation/make_multimethod.hpp> auto collide = make_multimethod( collide_go_go , collide_sh_sh , collide_sh_as , collide_as_sh , collide_as_as );
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

できた！ 衝突-マルチメソッドがあります。 autoを使用せずに、すぐに結果をテンプレート関数に渡し、boost :: function <const char *（game_object *、game_object *）> collide = ...を割り当てるか、明示的にmultimethod型<...>を指定します。 タイプを明示的に指定することは非常に難しく、自動演automaticを使用するのが最善です。 （boost | std | std :: tr1）::関数にカプセル化すると、特定のケースでは機能とパフォーマンスの一部が失われます（以下の説明例があります）が、一般に、ほとんどの場合、動作は同じです。



2番目の重要なポイント。 マルチメソッドを使用します。 私たちはすべてのゲームオブジェクトに対で直面しています

 auto& objs = get_obj_pointers(); for (size_t i = 0; i < objs.size(); ++i) for (size_t j = 0; j < objs.size(); ++j) cout << '\t' << collide(objs[i], objs[j]) << endl;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コンソールへの出力は、誰が実際に誰に遭遇したかを示します。 ご覧のとおり、階層には特別なディスパッチサポートは必要ありません。 Multimethodはデフォルトでdynamic_castを使用して、オブジェクトの実際の動的タイプを見つけます。 したがって、RTTIサポートを有効にしてコードをコンパイルする必要があります。

有効性を評価するために、コンパイル時に、collide（objs [i]、objs [j]）の呼び出しと同じマシンコードを与える擬似コードを提供します。





ご覧のとおり、実行時のオーバーヘッドはせいぜい2個のdynamic_castで表され、最悪の場合は4です。



ライブラリは、ポリモーフィックオブジェクトへのポインタで動作します：組み込み、およびスマートでユーザー定義のオブジェクトを使用します。 リンクを操作するために、ファサードref_multimethodを作成しました（<mml / generation / make_ref_multimethod.hpp>で実装）：



多態的なオブジェクトへのリンクの配列を作成するための便利なユーティリティ関数：





リンクを受け取るターゲット関数：





オブジェクトの衝突の同じサイクルを繰り返さないために、テンプレート関数でラップしました：

 template <typename F, typename Objs> void collide_tester(F collide, Objs& objs) { for (size_t i = 0; i < 2; ++i) for (size_t j = 0; j < 2; ++j) cout << '\t' << collide(objs[i], objs[j]) << endl; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

参照マルチメソッドを作成して使用します。

 #include <mml/generation/make_ref_multimethod.hpp> collide_tester( make_ref_multimethod( collide_ref_go_go , collide_ref_sh_sh , collide_ref_sh_as , collide_ref_as_sh , collide_ref_as_as ) , get_objs_refs() );
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

時間的に同等の擬似コードは、ポインターを使用した前の例と同じです。



機能オブジェクトは、埋め込みが簡単であるという点で、インライン関数へのポインターと比較して有利であると既に述べました。 それだけでなく、これらのオブジェクトのほとんどにはデータメンバがないため、ライブラリの腸で使用されるトリッキーな空のベース最適化手法を使用して、コンテナのメモリに格納できます。 ファンクターとのマルチメソッド相互作用の例を次に示します。

 struct collider_sh_as { const char* operator()(space_ship*, asteroid*) const { return "Space ship collides with asteroid"; } }; collide_tester( make_multimethod( collide_go_go , collide_sh_sh , collider_sh_as() , collide_as_sh , collide_as_as ) , get_obj_pointers() );
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ご覧のとおり、ファンクターの使用は組み込み関数を使用するのと同じくらい簡単です。 ただし、同時に、マルチメソッドのサイズは幅よりも1ポインター少なくなり、どのコンパイラーでもcollider_sh_as ::演算子（）の本体を呼び出し場所に簡単に埋め込むことができます。



ライブラリは、BOOST_TYPEOF（＆collider_sh_as :: operator（））を介してパラメータのタイプと呼び出し演算子の戻り値を決定します。 コンパイラがBOOST_TYPEOFをサポートしていない場合、またはBOOST_TYPEOFをサポートするためにカスタムタイプを登録したくない場合、またはそれが何であるかを知りたくない場合は、動揺しないでください。 パラメーターのタイプを明示的に指定できますが、これにはいくつかの便利な方法があります。 ライブラリーは、パラメーターのタイプとファンクター（F）の戻り値を判別するために、次のプロトコルを実装します。

1. F ::署名を介してファンクター型から機能型を取得しようとします。 次のように定義する必要があります。
   
   
   
   

    struct collider_sh_as { typedef const char* signature(space_ship*, asteroid*); ... }
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

   
   
   
2. 前のtypedefが欠落している場合、F :: result_type、F :: arg1_type、F :: arg2_type、...、F :: arg n _typeを介してファンクター内の型を見つけようとします。
   
   
   
   

    struct collider_sh_as { typedef const char* result_type; typedef space_ship* arg1_type; typedef asteroid* arg2_type; ... }
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

   
   
   したがって、このようなtypedefをエクスポートするboost ::関数は自動的にサポートされます。
   
   
   
   
3. 存在しない場合、F :: result_type、F :: argument_type（単項関数の場合）、F :: first_argument_type、F :: second_argument_type（バイナリ関数の場合）を介して型を見つけようとします。
   
   
   
   

    struct collider_sh_as { typedef const char* result_type; typedef space_ship* first_argument_type; typedef asteroid* second_argument_type; ... }
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

   
   
   または、はるかに便利です：
   
   
   
   

    struct collider_sh_as : std::binary_function<space_ship*, asteroid*, result_type> { ... }
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

   
   
   したがって、std :: unary_function、std :: binary_functionは自動的にサポートされます。
   
   
   
   
4. 前の3つのステップが機能しなかった場合、BOOST_TYPEOFが使用されます。 1つの非標準演算子（）を持つファンクターがサポートされます。 したがって、std ::関数およびC ++ 11ラムダがサポートされます。 一部のコンパイラは、カスタム型を登録する必要があります。 BOOST_TYPEOFがどのように機能するかはまだわかりません。ユーザータイプを登録しませんでした。MSVC7.1以降でパラメータータイプを完全に表示します。

前の例では、マルチメソッドは同じアリティの関数から組み立てられました。 これはライブラリの制限ではありません。

一般に、ライブラリは0〜MML_MAX_ARITYのアリティをサポートします。 MML_MAX_ARITYのデフォルトは5です。デフォルト値は変更できます。 これを行うには、ヘッダーを接続する前に、マクロを定義する必要があります。



#define MML_MAX_ARITY n

nは最大アリティです。



たとえば、ヌル、単項、三項関数を追加します。

 //   , ,     const char* collide_void() { return "Nothing collides?!"; } //     ,   const char* collide_go(game_object*) { return "Unsupported colliding!"; } const char* collide_sh(space_ship*) { return "Space ship collides with what?!"; } const char* collide_as(asteroid*) { return "Asteroid collides with what?!"; } const char* collide_go_go_go(game_object*, game_object*, game_object*) { return "Unsupported colliding!"; } const char* collide_sh_as_as(space_ship*, asteroid*, asteroid*) { return "Space ship collides with two asteroids"; } const char* collide_sh_as_st(space_ship*, asteroid*, space_station*) { return "Space ship collides with asteroid and space_station"; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

異なる数のオブジェクトをプッシュする新しいテスターが必要です。

 template <typename F, typename Objs> void collide_tester_var_arg(F collide, Objs& objs) { //   cout << '\t' << collide() << endl; // 1  cout << '\t' << collide(objs[0]) << endl; cout << '\t' << collide(objs[1]) << endl; // 2  cout << '\t' << collide(objs[0], objs[0]) << endl; cout << '\t' << collide(objs[0], objs[1]) << endl; // 3  cout << '\t' << collide(objs[0], objs[1], objs[1]) << endl; cout << '\t' << collide(objs[0], objs[1], objs[2]) << endl; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

マルチメソッドを作成して使用します。

 collide_tester_var_arg( make_multimethod( collide_go_go , collide_sh_sh , collide_sh_as , collide_void , collide_go , collide_sh , collide_as , collide_go_go_go , collide_sh_as_as , collide_sh_as_st ) , get_obj_pointers() );
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

したがって、マルチメソッドは、引数の数に関して静的にオーバーロードされた関数のように動作します。

擬似コードのレント相当はここでより興味深いものになります、それは引数の数に強く依存します：





多相型と値型を混在させることができます。 値型はそのまま渡されます。

int型の3番目のパラメーターを受け取ることができるいくつかの追加の目的関数を紹介します。

 const char* collide_go_go_int(game_object*, game_object*, int) { return "Unsupported colliding with extra int parameter!"; } const char* collide_sh_as_int(space_ship*, asteroid*, int) { return "Space ship collides with asteroid with extra int parameter"; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

明確にするために、テスターはマルチメソッドに送信します。

2つの多相型;

3ポリモーフィックタイプ;

2ポリモーフィックと1つの非ポリモーフィックタイプ：

 template <typename F, typename Objs> void collide_tester_non_polymorphic_arg(F collide, Objs& objs) { cout << '\t' << collide(objs[0], objs[1]) << endl; cout << '\t' << collide(objs[0], objs[1], objs[2]) << endl; cout << '\t' << collide(objs[0], objs[1], 1) << endl; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

以前のターゲット関数と新しいターゲット関数に基づいてマルチメソッドを作成し、以下を使用します。

 collide_tester_non_polymorphic_arg( make_multimethod( collide_go_go , collide_sh_sh , collide_sh_as , collide_as_sh , collide_as_as , collide_go_go_go , collide_sh_as_st , collide_sh_as_as , collide_go_go_int , collide_sh_as_int ) , get_obj_pointers() );
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最初の呼び出しと2番目の呼び出しに相当するRanthimeを指定しました。





ご覧のとおり、非多態的な引数は追加のオーバーヘッドにつながりません。



constおよびvolatile修飾子のオーバーロードもサポートされています。

 const char* collide_go_cvgo(game_object*, const volatile game_object*) { return "Unsupported colliding!"; } const char* collide_sh_cas(space_ship*, const asteroid*) { return "Space ship collides with const asteroid"; } const char* collide_sh_vas(space_ship*, volatile asteroid*) { return "Space ship collides with volatile asteroid"; } const char* collide_sh_cvas(space_ship*, const volatile asteroid*) { return "Space ship collides with const volatile asteroid"; } template <typename F, typename Objs> void collide_tester_cv(F collide, Objs& objs) { game_object* object = objs[1]; const game_object* c_object = objs[1]; const volatile game_object* cv_object = objs[1]; cout << '\t' << collide(objs[0], object) << endl; cout << '\t' << collide(objs[0], c_object) << endl; cout << '\t' << collide(objs[0], cv_object) << endl; } collide_tester_cv( make_multimethod( collide_sh_as , collide_go_cvgo , collide_sh_cas , collide_sh_vas , collide_sh_cvas ) , get_obj_pointers() ); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

マルチメソッドの重要な機能は、多相引数の正確なタイプがコンパイル段階ですでにわかっている場合にスケジューリングを最適化する機能です。つまり、実際のタイプの引数の検索は、階層ノードから始まります。これは、渡される引数の実際のタイプです。説明が簡単になります...例を見てみましょう：

 template <typename F, typename Objs> void collide_tester_compile_time_optim(F collide, Objs& objs) { space_ship ship; asteroid ast; cout << '\t' << collide(objs[0], &ast) << endl; cout << '\t' << collide(&ship, &ast) << endl; } collide_tester_compile_time_optim( make_multimethod( collide_go_go , collide_sh_sh , collide_sh_as , collide_as_sh , collide_as_as ) , get_obj_pointers() );
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、同等のランタイムを慎重に検討します。

 // collide(objs[0], &ast) inline const char* collide(game_object* obj1, asteroid* as2) { if (space_ship* sh1 = dynamic_cast<space_ship*>(obj1)) return collide_sh_as(sh1, as2); else if (asteroid* as1 = dynamic_cast<asteroid*>(obj1)) return collide_as_as(as1, as2); else return collide_go_go(obj1, as2); } //    : // min 1 cast // max 2 casts // collide(&ship, &ast) inline const char* collide(space_ship* sh1, asteroid* as2) { return collide_sh_as(sh1, as2); } //   !
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最初の呼び出しは最初の引数によってのみディスパッチされ、2番目の引数はそのまま渡されます。その型はコンパイル時に確実に既知です。

通常、2番目の呼び出しは単純な転送であり、両方の引数の型はコンパイル時に既知です。

そのため、このような最適化をサポートするために、可能であれば、マルチメソッドを純粋な形式で格納および送信し、boost :: function / * std :: function * /の後ろに隠れてはなりません。アップキャストを伴う呼び出し-衝突（（game_object *）＆ship、（game_object *）＆ast）-ライブラリから最適化の可能性を奪います。



マルチメソッドは、ベアポインターだけでなく、boost :: shared_ptr、およびテンプレートのペアを適切に特化したカスタムポインター型もサポートしています（詳細については、次の記事を参照）。boost :: shared_ptrをサポートするには、ヘッダーファイル<mml / casting / sp_dynamic_caster.hpp>を含める必要があります。

例：

 #include <mml/casting/sp_dynamic_caster.hpp> const char* sp_collide_go_go(game_object*, boost::shared_ptr<game_object>) { return "Unsupported colliding!"; } const char* sp_collide_sh_sh(space_ship*, boost::shared_ptr<space_ship>) { return "Space ship collides with smart_ptr space ship"; } struct sp_collider_sh_as { const char* operator()(space_ship*, boost::shared_ptr<asteroid>) const { return "Space ship collides with smart_ptr asteroid"; } }; template <typename F, typename Objs> void sp_collide_tester(F collide, Objs& objs) { boost::shared_ptr<game_object> obj1(new space_ship); boost::shared_ptr<game_object> obj2(new asteroid); cout << '\t' << collide(objs[0], obj1) << endl; cout << '\t' << collide(objs[0], obj2) << endl; } sp_collide_tester( make_multimethod( sp_collide_go_go , sp_collide_sh_sh , sp_collider_sh_as() ) , get_obj_pointers() );
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Ranthimeの同等物：





例のソースはこちらです。

メリット

. . , , . . . , .

( 0).

— compile time, .

短所

( ). , .. . - . , . , .

, .

性能

— dynamic_cast. dynamic_cast . , - . , «fast_cast», dynamic_cast . , . , ?

GUI . (inlining) .

, . Acyclyc Visitor , . dynamic_cast.

, , . ( , ) — .

依存関係

C++ 03 BOOST (headers only) 1.45.0 .



重要！コンパイラインクルードディレクトリ内に「boost」および「mml」ディレクトリが存在する必要があります。「boost」および「mml」ディレクトリ自体をincludeディレクトリとして指定せず、それらを含むディレクトリを指定します。



サンプル付きのライブラリは、コンパイラでテストされています（これまではWindowsでのみ）

。GCC3.4.2。

Visual C ++ 7.1、8.0、9.0、10.0



UPD： , , . , . , ( 57 ~190 ). , . , , if-else, .



UPD 2: : , C++ . , . , . mejedi .



. , .