.NETのアンマネージC ++ライブラリ。 完全統合

この記事では、Platform Invokeを使用した管理環境でのC ++ライブラリの完全な統合について説明します。 完全な統合とは、ライブラリクラスを継承し、そのインターフェイスを実装できることを意味します（インターフェイスはマネージコードで抽象クラスとして提示されます）。 相続人のインスタンスは、管理されていない環境に「転送」できます。

統合の問題はハブで何度も発生していますが、原則として、マネージコードでは実装できないいくつかのメソッドの統合に専念しています。 私たちのタスクは、C ++からモジュールを取得し、.NETで動作させることでした。 いくつかの理由で、再度書き込むオプションは考慮されなかったため、統合を開始しました。

この記事では、アンマネージモジュールを.NETに統合する際のすべての問題を開示しているわけではありません。 文字列や論理値などを渡すことにはまだ微妙な違いがあります。これらの問題に関するHabréに関するドキュメントといくつかの記事があるため、これらの問題はここでは考慮しませんでした。

Platform Invokeに基づく.NETラッパーはクロスプラットフォームであり、Mono + gccでアセンブルできることに注意してください。

シールドクラスの統合

Platform Invokeと統合するときに最初に気付かなければならないのは、このツールを使用すると特定の機能のみを統合できることです。 クラスを取得して統合することはできません。 問題の解決策は簡単に見えます：

非管理側では、関数を記述します。

SomeType ClassName_methodName(ClassName * instance, SomeOtherType someArgument) { instance->methodName(someArgument); } 

そのような関数にextern“ C”を追加して、それらの名前がC ++コンパイラーで修飾されないようにしてください。 これにより、これらの機能を.NETに統合できなくなります。

次に、クラスのすべてのパブリックメソッドに対して手順を繰り返し、結果の関数を.NETで記述されたクラスに統合します。 結果のクラスは継承できないため、.NETではこのようなクラスは封印済みとして宣言されます。 この制限を回避する方法とそれが関連付けられていること-以下を参照してください。
それまでの間、簡単な例を示します。

管理されていないクラス：

 class A { int mField; public: A( int someArgument); int someMethod( int someArgument); }; 

統合の機能：

 A * A_createInstance(int someArgument) { return new A(someArgument); } int A_someMethod(A *instance, int someArgument) { return instance->someMethod( someArgument); } void A_deleteInstance(A *instance) { delete instance; } 

.Netでの実装：

 public sealed class A { private IntPtr mInstance; private bool mDelete; [ DllImport( "shim.dll", CallingConvention = CallingConvention .Cdecl)] private static extern IntPtr A_createInstance( int someArgument); [ DllImport( "shim.dll", CallingConvention = CallingConvention .Cdecl)] private static extern int A_someMethod( IntPtr instance, int someArgument); [ DllImport( "shim.dll", CallingConvention = CallingConvention .Cdecl)] private static extern void A_deleteInstance( IntPtr instance); internal A( IntPtr instance) { Debug.Assert(instance != IntPtr.Zero); mInstance = instance; mDelete = false; } public A( int someArgument) { mInstance = A_createInstance(someArgument); mDelete = true; } public int someMethod( int someArgument) { return A_someMethod(mInstance, someArgument); } internal IntPtr getUnmanaged() { return mInstance; } ~A() { if (mDelete) A_deleteInstance(mInstance); } } 

アンマネージコードからクラスインスタンスを取得して返すには、内部コンストラクターとメソッドが必要です。 継承の問題は、クラスインスタンスをアンマネージ環境に戻すことに関連しています。 .NETでクラスAを継承し、そのメソッドの数を再定義する場合（someMethodがvirtualキーワードで宣言されていると仮定）、アンマネージ環境から再定義されたコードを呼び出すことはできません。

インターフェイス統合

インターフェイスを統合するには、フィードバックが必要です。 つまり 統合モジュールを完全に使用するには、そのインターフェイスを実装する機能が必要です。 実装は、管理対象環境でのメソッドの定義に関連しています。 これらのメソッドは、アンマネージコードから呼び出す必要があります。 ここで、Platform Invokeのドキュメントで説明されているコールバックメソッドが役立ちます。

環境の管理されていない側では、コールバックは関数へのポインターとして表示されます。

 typedef void (*PFN_MYCALLBACK )(); int _MyFunction(PFN_MYCALLBACK callback); 

.NETでは、デリゲートがその役割を果たします。

 [UnmanagedFunctionPointerAttribute( CallingConvention.Cdecl)] public delegate void MyCallback (); [ DllImport("MYDLL.DLL",CallingConvention.Cdecl)] public static extern void MyFunction( MyCallback callback); 

フィードバックツールを使用すると、オーバーライドされたメソッドへの呼び出しを簡単に提供できます。

しかし、管理されていない環境で、インターフェイスの実装のインスタンスを渡すには、実装のインスタンスとしても提示する必要があります。 したがって、管理されていない環境で別の実装を作成する必要があります。 ところで、この実装では、コールバック関数を呼び出します。

残念ながら、このアプローチでは、マネージインターフェイスでロジックなしでは実行できないため、抽象クラスの形式でロジックを提示する必要があります。 コードを見てみましょう：

管理されていないインターフェース：

 class IB { public: virtual int method( int arg) = 0; virtual ~IB() {}; }; 

管理されていない実装

 typedef int (*IB_method_ptr)(int arg); class UnmanagedB : public IB { IB_method_ptr mIB_method_ptr; public: void setMethodHandler( IB_method_ptr ptr); virtual int method( int arg); //... / }; void UnmanagedB ::setMethodHandler(IB_method_ptr ptr) { mIB_method_ptr = ptr; } int UnmanagedB ::method(int arg ) { return mIB_method_ptr( arg); } 

UnmanagedBメソッドは、マネージクラスが提供するコールバックを呼び出すだけです。 ここでもう1つ問題があります。 誰かがアンマネージコードでUnmanagedBへのポインターを持っている限り、コールバック呼び出しに応答するマネージコードでクラスインスタンスを削除する権利はありません。 記事の最後の部分では、この問題の解決に専念します。

統合の機能：

 UnmanagedB *UnmanagedB_createInstance() { return new UnmanagedB(); } void UnmanagedB_setMethodHandler(UnmanagedB *instance, IB_method_ptr ptr) { instance->setMethodHandler( ptr); } void UnmanagedB_deleteInstance(UnmanagedB *instance) { delete instance; } 

そして、マネージコードでのインターフェイスの表現は次のとおりです。

 public abstract class AB { private IntPtr mInstance; [DllImport("shim", CallingConvention = CallingConvention.Cdecl)] private static extern IntPtr UnmanagedB_createInstance(); [DllImport("shim", CallingConvention = CallingConvention.Cdecl)] private static extern IntPtr UnmanagedB_setMethodHandler( IntPtr instance, [MarshalAs(UnmanagedType.FunctionPtr)] MethodHandler ptr); [DllImport("shim", CallingConvention = CallingConvention.Cdecl)] private static extern void UnmanagedB_deleteInstance( IntPtr instance); [UnmanagedFunctionPointerAttribute( CallingConvention.Cdecl)] private delegate int MethodHandler( int arg); private int impl_method( int arg) { return method(arg); } public abstract int method(int arg); public AB() { mInstance = UnmanagedB_createInstance(); UnmanagedB_setMethodHandler(mInstance, impl_method); } ~AB() { UnmanagedB_deleteInstance(mInstance); } internal virtual IntPtr getUnmanaged() { return mInstance; } } 

各インターフェイスメソッドにはペアがあります。

1. 再定義するパブリック抽象メソッド
2. 抽象メソッド（接頭辞implを持つプライベートメソッド）の「呼び出し元」。 意味をなさないように見えるかもしれませんが、そうではありません。 このメソッドには、引数と実行結果の追加の変換が含まれる場合があります。 また、例外を渡すための追加のロジックを含めることもできます（ご想像のとおり、環境から環境に例外を渡すだけでは機能しないため、例外も統合する必要があります）

以上です。 これで、クラスABを継承し、そのメソッドmethodをオーバーライドできます。 相続人をアンマネージコードに渡す必要がある場合は、代わりにmInstanceを渡します。mInstanceは、関数/デリゲートへのポインターを介してオーバーライドされたメソッドを呼び出します。 管理されていない環境からIBインターフェイスへのポインターを取得する場合、管理された環境ではABインスタンスとして表す必要があります。 これを行うには、デフォルトのABの子孫を実装します。

 internal sealed class BImpl : AB { [DllImport("shim", CallingConvention = CallingConvention.Cdecl)] private static extern int BImpl_method( IntPtr instance, int arg); private IntPtr mInstance; internal BImpl( IntPtr instance) { Debug.Assert(instance != IntPtr.Zero); mInstance = instance; } public override int method(int arg) { return BImpl_method(mInstance, arg); } internal override IntPtr getUnmanaged() { return mInstance; } } 

統合の機能：

 int BImpl_method(IB *instance , int arg ) { instance->method( arg); } 

概して、これは上記の継承サポートのない同じクラス統合です。 BImplインスタンスを作成するときに、UnmanagedBインスタンスも作成し、不必要なコールバックバインディングを作成することに気付くのは難しくありません。 必要に応じて、これを回避できますが、これらは微妙なため、ここでは説明しません。

継承サポートとのクラス統合

目標は、クラスを統合し、そのメソッドをオーバーライドする機能を提供することです。 アンマネージのクラスへのポインターを提供するため、オーバーライドされたメソッドを呼び出すことができるように、クラスにコールバックを提供する必要があります。

アンマネージコードで実装されたCクラスを考えます。

 class C { public: virtual int method(int arg); virtual ~C() {}; }; 

そもそも、これがインターフェースであるふりをします。 上記のように 、これも統合します 。

管理されていないコールバックの継承者：

 typedef int (*_method_ptr )(int arg); class UnmanagedC : public cpp::C { _method_ptr m_method_ptr; public: void setMethodHandler( _method_ptr ptr); virtual int method( int arg); }; void UnmanagedC ::setMethodHandler(_method_ptr ptr) { m_method_ptr = ptr; } int UnmanagedC ::method(int arg ) { return m_method_ptr( arg); } 

統合の機能：

 //...   createInstance  deleteInstance void UnmanagedC_setMethodHandler(UnmanagedC *instance , _method_ptr ptr ) { instance->setMethodHandler( ptr); } 

.Netでの実装：

 public class C { private IntPtr mHandlerInstance; [DllImport("shim", CallingConvention = CallingConvention.Cdecl)] private static extern IntPtr UnmanagedC_setMethodHandler( IntPtr instance, [MarshalAs(UnmanagedType.FunctionPtr)] MethodHandler ptr); [UnmanagedFunctionPointerAttribute( CallingConvention.Cdecl)] private delegate int MethodHandler( int arg); //...     /   private int impl_method( int arg) { return method(arg); } public virtual int method(int arg) { throw new NotImplementedException(); } public C() { mHandlerInstance = UnmanagedC_createInstance(); UnmanagedC_setMethodHandler(mHandlerInstance, impl_method); } ~C() { UnmanagedC_deleteInstance(mHandlerInstance); } internal IntPtr getUnmanaged() { return mHandlerInstance; } } 

そのため、C.methodメソッドをオーバーライドでき、アンマネージ環境から正しく呼び出されます。 ただし、デフォルトの実装呼び出しは提供していません。 ここでは、記事の最初の部分のコードが役立ちます。
デフォルトの実装を呼び出すには、それを統合する必要があります。 また、その作業のために、クラスの適切なインスタンスが必要であり、作成および削除する必要があります。 使い慣れたコードを取得します。

 //...    createInstance  deleteInstance int C_method(C *instance, int arg) { return instance->method( arg); } 

.Net実装を終了しましょう。

 public class C { //... [DllImport("shim", CallingConvention = CallingConvention.Cdecl)] private static extern int C_method(IntPtr instance, int arg); public virtual int method(int arg) { return C_method(mInstance, arg); } public C() { mHandlerInstance = UnmanagedC_createInstance(); UnmanagedC_setMethodHandler(mHandlerInstance, impl_method); mInstance = C_createInstance(); } ~C() { UnmanagedC_deleteInstance(mHandlerInstance); C_deleteInstance(mInstance); } //... } 

このようなクラスは、マネージコードで安全に使用でき、そのメソッドを継承、オーバーライド、アンマネージ環境でクラスにポインターを渡すことができます。 メソッドをオーバーライドしなかった場合でも、UnmanagedCにポインターを渡します。 アンマネージコードがマネージコードを介してクラスCブロードキャスト呼び出しのアンマネージメソッドを呼び出すことを考えると、これはあまり合理的ではありません。 しかし、これはメソッドをオーバーライドする可能性の代価です。 この記事に添付されている例では、このケースはクラスDのメソッドmethodを呼び出すことによって示されています。コールスタックを見ると、次のシーケンスを確認できます。

例外

Platform Invokeは例外の受け渡しを許可しません。この問題を回避するために、環境から環境に移動する前にすべての例外をキャッチし、例外に関する情報を特別なクラスにラップして渡します。 一方、受信した情報に基づいて例外を生成します。

ラッキーです。 C ++モジュールは、ModuleException型またはその子孫の例外のみをスローします。 したがって、この例外を生成できるすべてのメソッドでこの例外をキャッチするだけで十分です。 例外オブジェクトを管理環境にスローするには、ModuleExceptionクラスを統合する必要があります。 理論上、例外にはテキストメッセージが含まれている必要がありますが、この記事の文字列マーシャリングのトピックに煩わされたくないので、例では「エラーコード」があります。

 public sealed class ModuleException : Exception { IntPtr mInstance; bool mDelete; //...  create/delete instance [DllImport("shim", CallingConvention = CallingConvention.Cdecl)] private static extern int ModuleException_getCode( IntPtr instance); public int Code { get { return ModuleException_getCode(mInstance); } } public ModuleException( int code) { mInstance = ModuleException_createInstance(code); mDelete = true; } internal ModuleException( IntPtr instance) { Debug.Assert(instance != IntPtr.Zero); mInstance = instance; mDelete = false; } ~ModuleException() { if (mDelete) ModuleException_deleteInstance(mInstance); } //...  getUnmanaged } 

ここで、C ::メソッドがModuleExceptionをスローできると仮定します。 例外サポートを使用してクラスを書き換えます。

 //    ,     typedef int (*_method_ptr )(int arg, ModuleException **error); int UnmanagedC ::method(int arg ) { ModuleException *error = nullptr; int result = m_method_ptr( arg, &error); if (error != nullptr) { int code = error->getCode(); //...    error      throw ModuleException(code); } return result; } 

 int C_method(C *instance, int arg, ModuleException ** error) { try { return instance->method( arg); } catch ( ModuleException& ex) { *error = new ModuleException(ex.getCode()); return 0; } } 

 public class C { //... [DllImport("shim", CallingConvention = CallingConvention.Cdecl)] private static extern int C_method(IntPtr instance, int arg, ref IntPtr error); [UnmanagedFunctionPointerAttribute( CallingConvention.Cdecl)] private delegate int MethodHandler( int arg, ref IntPtr error); private int impl_method( int arg, ref IntPtr error) { try { return method(arg); } catch (ModuleException ex) { error = ex.getUnmanaged(); return 0; } } public virtual int method(int arg) { IntPtr error = IntPtr.Zero; int result = C_method(mInstance, arg, ref error); if (error != IntPtr.Zero) throw ModuleException(error); return result; } //... } 

ここでも、メモリ管理に問題があります。 impl_methodメソッドでは、エラーへのポインターを渡しますが、ガベージコレクターはアンマネージコードで処理される前にそれを削除できます。 この問題に対処する時が来ました！

コールバックガベージコレクター

ここで私は多かれ少なかれ幸運だと言わなければなりません。 統合モジュールのすべてのクラスとインターフェイスは、addRefメソッドとreleaseメソッドを含む特定のIObjectインターフェイスから継承されます。 モジュール内のすべての場所で、ポインターが渡されるとaddRef呼び出しが行われることを知っていました。 そして、ポインタの必要性がなくなるたびに、リリースの呼び出しが行われました。 このアプローチにより、モジュールにアンマネージポインターが必要かどうか、またはコールバックを既に削除できるかどうかを簡単に追跡できます。

管理対象外環境で使用される管理対象オブジェクトの削除を回避するには、これらのオブジェクトのマネージャーが必要です。 addRefを読み取り、アンマネージコードから呼び出しを解放し、マネージオブジェクトが不要になったら解放します。

addRefおよびreleaseの呼び出しは、アンマネージコードからマネージコードにスローされるため、最初に必要なのは、このような転送を提供するクラスです。

 typedef long (*UnmanagedObjectManager_remove )(void * instance); typedef void (*UnmanagedObjectManager_add )(void * instance); class UnmanagedObjectManager { static UnmanagedObjectManager mInstance; UnmanagedObjectManager_remove mRemove; UnmanagedObjectManager_add mAdd; public: static void add( void *instance); static long remove( void *instance); static void setAdd( UnmanagedObjectManager_add ptr); static void setRemove( UnmanagedObjectManager_remove ptr); }; UnmanagedObjectManager UnmanagedObjectManager ::mInstance; void UnmanagedObjectManager ::add(void * instance ) { if (mInstance.mAdd == nullptr) return; mInstance.mAdd( instance); } long UnmanagedObjectManager ::remove(void * instance ) { if (mInstance.mRemove == nullptr) return 0; return mInstance.mRemove( instance); } void UnmanagedObjectManager ::setAdd(UnmanagedObjectManager_add ptr ) { mInstance.mAdd = ptr; } void UnmanagedObjectManager ::setRemove(UnmanagedObjectManager_remove ptr) { mInstance.mRemove = ptr; } 

次に行う必要があるのは、addRefとIObjectインターフェイスのリリースを再定義して、マネージコードに格納されているマネージャーのカウンター値を変更することです。

 template <typename T > class TObjectManagerObjectImpl : public T { mutable bool mManagedObjectReleased; public: TObjectManagerObjectImpl() : mManagedObjectReleased( false) { } virtual ~TObjectManagerObjectImpl() { UnmanagedObjectManager::remove(getInstance()); } void *getInstance() const { return ( void *) this; } virtual void addRef() const { UnmanagedObjectManager::add(getInstance()); } virtual bool release() const { long result = UnmanagedObjectManager::remove(getInstance()); if (result == 0) if (mManagedObjectReleased) delete this; return result == 0; } void resetManagedObject() const { mManagedObjectReleased = true; } }; 

次に、UnmanagedBクラスとUnmanagedCクラスをTObjectManagerObjectImplクラスから継承する必要があります。 UnmanagedCの例を考えてみましょう。

 class UnmanagedC : public TObjectManagerObjectImpl <C> { _method_ptr m_method_ptr; public: UnmanagedC(); void setMethodHandler( _method_ptr ptr); virtual int method( int arg); virtual ~UnmanagedC(); }; 

CクラスはIObjectインターフェイスを実装していますが、addRefメソッドとreleaseメソッドはTObjectManagerObjectImplクラスによってオーバーライドされるため、管理環境のオブジェクトマネージャーはポインターの数を計算します。
マネージャー自身のコードを見てみましょう。

 internal static class ObjectManager { //...  ,  , .  private static AddHandler mAddHandler; private static RemoveHandler mRemoveHandler; private class Holder { internal int count; internal Object ptr; } private static Dictionary< IntPtr, Holder> mObjectMap; private static long removeImpl( IntPtr instance) { return remove(instance); } private static void addImpl(IntPtr instance) { add(instance); } static ObjectManager() { mAddHandler = new AddHandler(addImpl); UnmanagedObjectManager_setAdd(mAddHandler); mRemoveHandler = new RemoveHandler(removeImpl); UnmanagedObjectManager_setRemove(mRemoveHandler); mObjectMap = new Dictionary<IntPtr , Holder >(); } internal static void add(IntPtr instance, Object ptr = null) { Holder holder; if (!mObjectMap.TryGetValue(instance, out holder)) { holder = new Holder(); holder.count = 1; holder.ptr = ptr; mObjectMap.Add(instance, holder); } else { if (holder.ptr == null && ptr != null) holder.ptr = ptr; holder.count++; } } internal static long remove(IntPtr instance) { long result = 0; Holder holder; if (mObjectMap.TryGetValue(instance, out holder)) { holder.count--; if (holder.count == 0) mObjectMap.Remove(instance); result = holder.count; } return result; } } 

これでオブジェクトマネージャができました。 管理対象オブジェクトのインスタンスを管理対象外環境に渡す前に、それをマネージャーに追加する必要があります。 したがって、クラスABおよびCのgetUnmanagedメソッドを変更する必要があります。 クラスCのコードは次のとおりです。

 internal IntPtr getUnmanaged() { ObjectManager.add(mHandlerInstance, this); return mHandlerInstance; } 

これで、コールバックが必要な限り機能することを確認できます。

モジュールの仕様を考慮して、クラスを書き換え、ClassName_deleteInstanceへのすべての呼び出しをIObject :: releaseへの呼び出しに置き換え、必要に応じてIObject :: addRefを実行することも忘れないでください。 特に、これは、ガベージコレクターがマネージラッパーを削除した場合でも、ModuleExceptionの時期尚早な削除を回避するのに役立ちます。

おわりに

実際、モジュールを統合している間、私たちは膨大な感情を経験し、多くのわいせつな言葉を学び、立ったまま眠ることを学びました。 おそらく、この記事を誰かに役立つものにしたいのですが、神は禁じられています。 もちろん、メモリ管理、継承、および例外を渡す問題を解決するのは楽しかったです。 しかし、3つのクラスからはほど遠く統合し、1つのメソッドからは程遠いものでした。 耐久テストでした。

それでもこのような問題が発生する場合は、Sublime Text、正規表現、スニペットが大好きです。 この小さなセットはアルコール依存症から私たちを救いました。

PSライブラリ統合の実例は、 github.com / simbirsoft-public / pinvoke_exampleで入手できます。