6

私のアプリケーション全体（20MBの実行可能ファイルを備えたかなり大きい）は、アンマネージC++で記述されています。マネージコードを使用する利点がはっきりとわかるので、アプリケーションにマネージコードを導入したいのですが、どこから始めればよいですか？

C ++ / CLIの使用を簡単に開始して、アプリケーションの他の部分とリンクできますか？（C ++ / CLI構文はかなり「エキゾチック」に見えますが）。

または、C＃に移行する方が良いのですが、これをアンマネージC ++コードと「リンク」するための最良の方法は何ですか？

/clrオプションを使用してすべてのC++コードをコンパイルすることは意味がありますか？これは機能しますか？

マーシャリングについて心配する必要がありますか？これはオーバーヘッドをもたらしますか、それともパフォーマンスを低下させることなくマネージドとアンマネージドを切り替えることができますか（20年前にFortranとCを混合したときと同じように）。パフォーマンスは、数ギガバイトのメモリを処理することがある科学的なアプリケーションであるため、私のアプリケーションでは非常に重要です。

または、ユーザーインターフェイスを再設計し、これをC＃で記述し、アプリケーションの残りの部分（計算ロジック、ビジネスロジック、データベースインターフェイスなど）をアンマネージC ++で保持することだけが意味がありますか？

私のアプリケーションは時々数ギガバイトのメモリを処理する必要があるので、64ビットのバリアントがあります。64ビットのマネージコードを使用するのは簡単ですか？それだけのメモリが使用されている場合でも、ガベージコレクタは効率的ですか？

簡単に言うと、どこから始めればよいですか？

パトリック

4

3 に答える 3

1

アプリのプロファイルを作成し、C＃のロジックラインから切り離してC++に割り込むことができる統合ポイントを決定します。その逆も同様です。これらを計画にまとめて、Facadeデザインパターンをシステム内で移動させ、C ++をC＃に徐々に置き換えます。重要な懸念事項は、各候補ファサード/インターフェイスで言語を切り替えることを決定する際のCPUとメモリのコストです。

編集を組み込むことができるようにしたいので、元のC ++コード用の1つのソースコードセットとソースコードリポジトリ、およびファサードとC＃用の別のセットとリポジトリを使用するのが最適です。

次に、拡張機能/メンテナンス作業がトレイに入ると、両方のコードベースに適用し、拡張機能またはメンテナンスで変更される可能性が最も低いコードからファサードがシステム内を移動するようにして、変更作業の倍増を最小限に抑えます。 。

また、理想的には、ファサードをロールバックして、障害が発生した場合に帽子をかぶっただけで100％C++に戻ることができるように作業を構成します。

いくつかの特に不可解なC++モジュールをC++ピースとC＃ピースに分離できるかどうかをテストするには、パイプまたはソケットを使用して通信する2つの異なるWin32C++プロセスでそれらを実行します。そうすることで、その時点でコールチェーンを分割する前に、修正が必要なメモリ管理またはパフォーマンスの問題があるかどうかをより正確に把握できます。

于 2009-12-17T17:30:57.937 に答える
1

何千人ものユーザーが使用するミッションクリティカルなアプリケーションで、あなたが説明したことを正確に実行します。基本的に、既存のアプリケーションをそのままにしておいたので、実行可能ファイルは100％アンマネージド実行可能ファイルです（C ++ / CLIではありません）。次に、すべての新しいC＃コードをビジネスオブジェクト、ユーザーコントロール、GUIコードなどで構成される.NETdllに配置します。

基本的に、すべての新しいコードはC＃で記述されています。ただの接着剤であるC++/CLIである1つのdllがあります。これにより、既存のC ++コードをclrにすることなく、マネージコードとアンマネージコードを簡単に相互運用できます。これにより、記述しなければならないC ++/CLIコードの量が制限されます。ネイティブコードは、マネージコードと通信できる混合モードコードと通信します。混合モードdllはC＃クラスでイベントをフックできるため、C＃コードはイベントを発生させてC ++ / CLI（ネイティブコードと通信できます）と通信できます。

既存のC++アプリで.NETUserControlsをホストすることもできます（WinFormsはとにかくWINAPIの単なるラッパーであるため、非常にうまく機能します）。

これは非常にうまく機能し、C＃でGUI全体を書き直すことなく既存のコードを維持できます。

于 2009-12-18T03:12:35.787 に答える
1

今のところ、この質問は閉じられていると考えてください。

答えはC++とC＃を混在させることではなく、そもそもアーキテクチャを正しくすることであることに気づきました。

アーキテクチャが正しく、分離する必要がある場所で分離されている場合は、アプリケーションの一部を他のモジュール（外部、他の言語など）で変更するよりも簡単です。

マーシャリング中のパフォーマンスの問題については、.Netがさらに成熟するまで待つ必要があります。

于 2010-02-10T13:22:42.200 に答える