C#にunsafe
キーワードがある場合、Cライブラリと相互運用することが依然として有益である状況はありますか?
既存のCライブラリを使用して、非常に高速な数値処理、グラフィカルな操作、または行列演算の必要性を理解できました。しかし、たとえばC99でグリーンフィールドDLLを作成し、C#から相互運用するための使用例はありますか?
必要なパフォーマンス特性を得るには、Cにドロップすることが(金属に近いという意味で)唯一の方法である場合があると思います。
C#にunsafe
キーワードがある場合、Cライブラリと相互運用することが依然として有益である状況はありますか?
既存のCライブラリを使用して、非常に高速な数値処理、グラフィカルな操作、または行列演算の必要性を理解できました。しかし、たとえばC99でグリーンフィールドDLLを作成し、C#から相互運用するための使用例はありますか?
必要なパフォーマンス特性を得るには、Cにドロップすることが(金属に近いという意味で)唯一の方法である場合があると思います。
回答:
CにはC#よりもいくつかの機能があります。
Cでリアルタイムコードを実行できます。Windowsが最適なプラットフォームではありません。しかし、私はそれでリアルタイム制御システムを作りました。それをC#で行うのはいいことです。ほとんどの場合、予測可能ですが、常にそうであるとは限りません。これは、RTシステムにとっては致命的です。
多くのプラットフォーム(Linux / Windowsだけでなく、任意の数の組み込みシステム)でのCコードの移植性。CとC#バージョンのコードではなく、C#相互運用機能を備えた1つのライブラリーを用意するよりも、暗号化やウィンドウから組み込みデバイスへの圧縮などを使用しています。
1つ目は、unsafe
Cの相互運用よりもはるかに便利です。たとえば、「セーフ」モードでは、実際のピクセルデータを使用して画像分析を行うと、速度が著しく低下することがあります。安全でないモードに切り替え、画像バッファーに直接アクセスして同じ作業を行うと、桁違いに速くなります。
.Netプロジェクトに含めるためにC / C ++で大規模な開発を行うことは確かに理にかなっていますが、すべてパフォーマンスにかかっています。古典的なアドバイスは、アプリケーション全体を選択した言語で記述してからプロファイルすることです。処理時間が50%以上かかり、マネージ言語を使用しているときに現実的に調整できないコードの重要なセクションを見つけたら、Cでその1つのルーチンを再実装して統合します。
実際の例:経路探索アルゴリズムのプロトタイプを作成していました。C#で動作することを示した後、1秒間に何度も実行できるように十分高速にする必要がありました。ルーティングの決定や結果などに使用されるすべての要素を示す、C#でいくつかの素晴らしいサポートUIを既に構築していたので、ルーティングアルゴリズムのコア部分をC ++で再実装しました。私がC ++で始めたとしたら、私はそこまでたどり着いたのではないかと思います。
しかし、たとえばC99でグリーンフィールドDLLを作成し、C#から相互運用するための使用例はありますか?
私が目にする主なユースケースは、CまたはC99が利用可能な多くのプラットフォームを対象とする特別なlibを作成する場合ですが、C#は利用できないか、それらの一部のみを対象としています(「C#」は組織では利用できない場合があります)純粋な技術的な理由だけではありません)。
もう1つの使用例は、特定のハードウェアに関する専門家など、特定の分野の専門家がいて、彼の専門知識の一部をライブラリにコーディングするタスクがあるが、その専門家はCで30年の経験がある場合です。 C#ではありません。
考慮すべきことの1つは、「100%緑地」は今日、非常にまれな状況です。ほとんどの種類の問題では、少なくとも部分的な解決策が存在するか、修正時に再利用できる同様の解決策があります。そのため、既存のCコードベースで何か新しいものを構築する必要がある場合、Cを使用することは非常に理にかなっています。