CXXI：C＃とC ++の世界をつなぐ

Monoランタイムには、.NET以外の言語のコードとやり取りするためのツールがたくさんありますが、C ++のコードとやり取りするのに正気はありませんでした。



しかし、Alex Corrado、Andrea Gait、およびZoltan Vargの仕事のおかげで、それはすぐに変わります。



要するに、新しいテクノロジーにより、C＃/。

• C＃またはその他の.NET言語のC ++クラスを簡単かつ透過的に使用する
• CからC ++クラスのインスタンスを作成します＃
• C＃コードからC ++クラスメソッドを呼び出す
• C＃コードからインラインC ++メソッドを呼び出します（ライブラリが-fkeep-inline-functionsフラグでコンパイルされている場合、または実装で追加のライブラリをコンパイルする場合）
• CからC ++クラスを継承する＃
• C＃メソッドでC ++クラス仮想メソッドをオーバーライドする
• このような混合C ++ / C＃クラスのインスタンスをC＃およびC ++コードの両方で使用する

CXXI（ およそTransl 。：「セクシー」と読みます）は、MonoとC ++コードの相互作用を改善するために、GoogleのSummer of Codeの後援の下で2か月間作業した結果です。

代替案

Monoには、主にECMA標準から継承された、.NET以外の言語のコードとやり取りするためのメカニズムがいくつか用意されていることを思い出してください。 これらのメカニズムは次のとおりです。

1. マネージコード（C＃）がアンマネージライブラリから関数を呼び出し、これらのライブラリのコードをマネージコードにコールバックできるようにする、双方向プラットフォーム呼び出し（P /呼び出し）テクノロジ。
2. COM Interopにより、Monoで実行されているコードは、このコードがいくつかのCOM規則に準拠している限り、アンマネージドCまたはC ++コードを透過的に呼び出すことができます（これらの規則は非常に簡単です：標準vtableマークアップ、Add、ReleaseおよびQueryInterfaceメソッドの実装、 MonoとCOMライブラリの間でマーシャリングできる標準のタイプセット）。
3. 呼び出しを傍受するための一般的な技術 。これにより、オブジェクトのメソッドへの呼び出しを傍受し、さらにそれをどう処理するかを独立して理解することができます。

しかし、C＃でC ++オブジェクトを使用する場合、その選択はあまり期待できません。 たとえば、C＃から次のC ++クラスを使用するとします。

class MessageLogger { public: MessageLogger (const char *domain); void LogMessage (const char *msg); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このクラスをC＃コードに提供する1つの方法は、COMオブジェクトでラップすることです。 これは一部の高レベルオブジェクトで機能する場合がありますが、ラッピングプロセスは非常に面倒で日常的な作業です。 この面白くないアクティビティがここにどのように見えるかを見ることができます 。



もう1つのオプションは、P / Invokeを介して呼び出すことができるアダプターをリベットすることです。 上記のクラスの場合、これらは次のようになります。

 /* bridge.cpp,   bridge.so */ MessageLogger *Construct_MessageLogger (const char *msg) { return new MessageLogger (msg); } void LogMessage (MessageLogger *logger, const char *msg) { logger->LogMessage (msg); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

C＃の部分は次のようになります。

 class MessageLogger { IntPtr handle; [DllImport ("bridge")] extern static IntPtr Construct_MessageLogger (string msg); public MessageLogger (string msg) { handle = Construct_MessageLogger (msg); } [DllImport ("bridge")] extern static void LogMessage (IntPtr handle, string msg); public void LogMessage (string msg) { LogMessage (handle, msg); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そのようなラッパーをコンパイルするのに30分座って、ライブラリの作成者、コンパイラ、C ++、C＃の作成者を殺し、この致命的で不完全な世界を完全に破壊したいのです。



PhyreEngine＃は、SonyのPhyreEngineの.NET C ++ APIバインディングです。 コードを書くプロセスは非常に退屈でした。そのため、ひざまずいてコードジェネレーターのようなことをしました。



さらに、上記のメソッドでは、C ++コードでC ++クラスメソッドをオーバーライドすることはできません。 より正確には、これを行うことができますが、これには多くの特殊なケースと多くのコールバック呼び出しを考慮して、大量のコードを手動で記述する必要があります。 バインディングはすぐにほとんどサポートされなくなります（PhyreEngineのバインダーを作成するときにこの問題に遭遇しました）。



上記の試練は、CXXIの作成を促しました。

仕組み

C ++クラスへのアクセスは複雑な問題です。 CXXIで大きな役割を果たすC ++コードの実装の機能について簡単に説明します。

• オブジェクトレイアウト：メモリ内のオブジェクトのバイナリ表現は、プラットフォームによって異なる場合があります。
• VTableマークアップ：コンパイラがメソッドのアドレスを決定するために使用する仮想メソッドの実装へのポインターのリストは、クラスとその親の仮想メソッドに依存します。
• 装飾名 ：vtableに含まれていない非仮想メソッド。 コンパイラは、通常の「C」関数を生成します。この関数の名前は、戻り値の型と引数の型に基づいて計算されます。 装飾スキームはコンパイラーに依存します。

たとえば、次のクラスがあります。

 class Widget { public: void SetVisible (bool visible); virtual void Layout (); virtual void Draw (); }; class Label : public Widget { public: void SetText (const char *text); const char *GetText (); };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これらのメソッドメソッドのC ++コンパイラは、次の名前を生成します（approx.per .: GCCやIntel C ++ Compiler for Linuxなどの意味のコンパイラ、スタジオは次のような読み取り不可能なものを生成しますか？H @@ YAXH @ Z; GCCの場合、c +ユーティリティを使用できます+ filt）：

__ZN6Widget10SetVisibleEb

__ZN6Widget6LayoutEv

__ZN6Widget4DrawEv

__ZN5Label7SetTextEPKc

__ZN5Label7GetTextEv







ここにコードがあります

  Label *l = new Label (); l->SetText ("foo"); l->Draw ();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次のようなものにコンパイルされます（Cコードとして表されます）。

  Label *l = (Label *) malloc (sizeof (Label)); ZN5LabelC1Ev (l); //    Label _ZN5Label7SetTextEPKc (l, "foo"); //    Draw (l->vtable [METHOD_PTR_SIZE*2])();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

CXXIがそのようなことをサポートするためには、vtable内のメソッドの正確な位置、各メソッドが実装されている場所と方法、および装飾名でそれらに到達する方法を知る必要があります。



以下の図は、C ++ライブラリがC＃およびその他の.NET言語でどのように利用可能になるかを示しています。





実際、C ++コードは2回コンパイルされます。 C ++コンパイラはアンマネージライブラリを生成し、CXXIツールキットはバインダーを生成します。



一般的に、CXXIに必要なのはC ++コードのヘッダーファイルのみで、C＃で使用するためにラップする必要があるのはヘッダーファイルのみです。 そのため、独自のライブラリとヘッダーファイルしかない場合でも、CXXIはバインダーを生成できます。



CXXIツールキットは、C＃およびその他の.NET言語から安全に使用できる通常の.NETライブラリ（ およそTransl 。：これはMSILを含み、アンマネージコードのみを含むPre-Donetsライブラリです）を作成します。 このライブラリは、次のプロパティを持つC＃クラスを公開します。

• C＃クラスのインスタンスを作成すると、そのコンストラクターは対応するC ++クラスのインスタンスを作成します。
• これらのクラスは他のC＃クラスの基本となることができ、仮想としてマークされたすべてのメソッドはC＃コードでオーバーライドできます。
• C ++クラスの多重継承がサポートされています。生成されたC＃クラスは、さまざまなC ++基本クラスにアクセスできるタイプ変換演算子のセットを実装します。
• オーバーライドされたメソッドは、C＃baseキーワードを使用してC ++ベースクラスメソッドを呼び出すことができます。
• 多重継承の場合を含む、仮想クラスメソッドをオーバーライドできます。
• 他の人がすでに作成したC ++クラスのインスタンスを使用する場合に備えて、IntPtrを受け入れるコンストラクターもあります。

CXXIパイプラインは、右の図に示す3つのコンポーネントで構成されています。



GCC-XMLコンパイラは、C ++コードを解析し、そこから必要な情報を抽出するために使用されます。 生成されたXMLは、CXXIユーティリティによって処理され、C ++のクラスへの実際のブリッジを含むC＃の部分クラスのセットが生成されます



次に、追加する追加コード（たとえば、APIを改善するためのオーバーロードされたいくつかのメソッド、ToStringの実装、非同期メソッドなど）と組み合わされます。



出力は、ネイティブライブラリで動作する.NETアセンブリです。



このアセンブリには、メモリ内のオブジェクトをマークするためのマップが含まれていないことに注意してください。 代わりに、CXXIバインダは、ABIが実行されたときに使用された変換ルールと対応する変換ルールに基づいてこれを決定します。 したがって、バインダーをコンパイルする必要があるのは一度だけで、それから異なるプラットフォームで静かに使用します。

例

GitHubプロジェクトコードには、さまざまなテストと多数のサンプルが含まれています。 それらの1つは、Qtへの最小限のバインディングです。

他に実装するもの

残念ながら、CXXIプロジェクトはまだ完成していませんが、これは.NETとC ++でのコードの相互作用を明確に改善するための十分な準備です。



現在、CXXIはランタイムですべての作業を実行し、必要に応じてSystem.Reflection.Emitを介してアダプターを生成します。これにより、C ++ライブラリコンパイラで使用されるABIを動的に決定できます。



また、静的コンパイルのサポートを追加します。これにより、PS3およびiPhoneのC＃ライターでこのテクノロジーを使用できるようになります。



CXXIは現在、ABI GCCをサポートしており、ABI MSVCを最初にサポートしています。 他のコンパイラのABIサポートの実装とMSVCサポートの完了を支援させていただきます。



現在、CXXIは、それによって作成されたオブジェクトの削除のみをサポートしています。 他のすべてのオブジェクトは、アンマネージコードの世界に属すると見なされます。 このようなオブジェクトの削除演算子のサポートも役立ちます。



また、パイプラインとランタイムAPIをより適切に文書化し、バインダー自体を改善したいと考えています。

翻訳者から

この方法は、C ++ / CLIで大量のグルーコードを書くのと比べて有利です。ここではすべての作業があなたのために行われ、すべてがクロスプラットフォームになります。 また、C ++でクラスメソッドをキックする同様の方法についての記事がその年にハブに登場しましたが、多くは手作業で行われましたが、注目に値します。 しかし、著者によると、オンザフライラッパーの使用は、COM相互運用（MSからのランタイム）よりも1.5倍高速であることが判明しました。

そうそう。 これは記事には反映されていませんが、githubのテストケースから判断すると、C ++オブジェクトのフィールドを参照できます。

どのくらい使いやすいですか？ 理論的には、任意のプラスlibを使用して、そのためのバインダーを生成できます（Windowsの場合、Cygwinでコンパイルする必要があります）。 そして、オブジェクトの新しく作成されたインスタンスを返すメソッドがない場合は正常に機能しますが、現時点では削除できませんが、QtではQObjectにdeleteLater（）スロットがあり、問題はないはずです。 実際には、Irrlichtのバインダーを生成しようとして一般的なものが落ち、GCCXMLはstd :: tr1から何かをマスターすることなくOGREに落ちました。 一般的に、GCCXMLによって更新されることはめったにないので、clangを優先してGCCXMLを放棄する価値がありますが、結局のところ、正しく動作します。 しかし、例の中にはいくつかのQtGuiクラス用の動作バインダーがあります（不完全で、これまでにすべてのメタ情報とシグナルスロットでQObjectインフラストラクチャを行った人はいません）。