2

ネイティブのWin32C++コードと、C ++コードから呼び出したいC＃アセンブリのセットがあります。私は私たちのオプティオスを次のように要約します：

  1. COMを使用します。C＃コードは、追加の属性（GUID、COMVisible）で装飾する必要があります。C＃アセンブリはregasmに登録する必要があり、COMを介してネイティブC++コードで使用できるようになります。

  2. C ++ / CLI（以前はマネージC ++）ラッパークラスを使用します。C++クラスをネイティブC++プロジェクトに追加できます。そのクラスは/clrでコンパイルされます。ネイティブC++コードはC++/ CLIクラスを呼び出し、C ++/CLIクラスは.Netコードを呼び出します。COMは関与しません。CLRは、C ++ / CLI拡張機能によって処理されるマーシャリングで、必要に応じて魔法によって開始されます。

  3. ネイティブC++コードでCLRのインスタンスをホストします。

ラッパークラスの必要性がなくなることを除いて、オプション2に勝る利点が見当たらないため、オプション3を割引します。だから問題は、オプション1とオプション2の長所/短所は何ですか？

前もって感謝します。

4

3 に答える 3

3

オプション2は最高のパフォーマンスを発揮し、最もシームレスで保守しやすいIMOになります。

私が見つけたオプション1には実際には利点はありません。C ++ / CLIを使用すると、機能が大幅に向上し、動作が速くなり、一般的にはるかに簡単になるようです。

ところで、ラッパークラスがなくてもC＃アセンブリを直接使用することもできます。これには、/ CLRで使用するファイルをコンパイルする必要がありますが、非常にうまく機能します。

于 2009-07-01T15:25:36.723 に答える
1

オプション1の場合、メインのプロは、プロジェクトによっては厄介になる可能性のあるラッパークラスを作成する必要がありません。

オプション2の場合、管理されていない使用を容易にするために管理対象ライブラリーを変更する必要はありませんが、これはオプションではない場合があります。

私にとっては、コードを変更したい場所に行き着きます。

于 2009-07-01T15:30:36.540 に答える
1

オプション2を使用すると、アプリケーション全体をC ++ / CLIに変換して、管理対象/非管理対象の遷移を回避する非常に簡単な方法も利用できます。参照されるアセンブリをどのように使用するか、つまりパフォーマンスに影響を与えるかどうかによっては、遷移が問題になる可能性があります。

これまでのところ、私はC ++ / CLIで前向きな経験しかなく、そのルートに進むことをお勧めできます。

于 2009-07-02T05:24:18.847 に答える