C＃でアンマネージセーフコードを使用しないのはなぜですか

C＃には、チェックされていないコードを実行するオプションがあります。マネージコードの方がはるかに安全であり、多くの問題を克服できるため、通常はそうすることはお勧めしません。

ただし、コードでエラーが発生しないことが確かで、メモリの処理方法がわかっている場合、なぜ（高速コードが好きな場合）なぜ一般的なアドバイスに従うのでしょうか。

非常に高速なビットマップ操作を必要とするビデオカメラ用のプログラムを書いたので、これは不思議に思っています。私はいくつかの高速グラフィカルアルゴリズムを自分で作成し、アンマネージコードを使用してビットマップ上で優れた動作をしました。

一般的に、メモリリークやクラッシュのリスクがないことが確かな場合は、アンマネージコードをより頻繁に使用しないのはなぜでしょうか。

PS私の経歴：このプログラミングの世界に少し入って、私は一人で（数年はそうしています）、このソフトウェア設計の質問がそれほど奇妙ではないことを願っています。先生のように、そんなことを聞​​いてくれる人はあまりいません。

まあ、それは主に古くからの格言の場合です

• 最適化しない
• （専門家のみ）まだ最適化しないでください

しかし、実際には、危険なコードを回避する3つの主な理由を考えることができます。

1. バグ：質問の重要な部分は、「コードでエラーが発生しないことが確実な場合」です。ええと、どうすれば絶対に完全に確信できますか？コードが正しいことを保証する正式な方法で証明者を使用しましたか？プログラミングにおいて確かなことの1つは、バグが発生することです。あなたが安全を脱ぐとき、あなたは新しい種類のバグが谷を這うのを許します。ガベージコレクターにメモリの処理を任せると、多くの問題がなくなります。

2. 思ったほど速くない場合もあります。もう1つのポイントは、問題によっては、それほど大きくはならない場合があります。今は見つけられないようですが、Java、Scala、Go、C ++の速度を比較したGoogleの研究を覚えています。いったん地上に最適化されると、もちろんC ++ははるかに高速でした。しかし、「慣用的」な方法でプログラムされたアルゴリズムは、それほど高速ではありませんでした。標準的な構造とイディオム（stlコンテナー、展開されていないループなど）を使用していたという意味での慣用的。マイクロソフトは、C＃およびC ++でも同様の実験を行いました。マイクロソフトのトップエンジニアの1人であるレイモンドチェンは、C＃に勝つために独自のstd :: stringの実装を作成する必要がありました。（参照：http : //www.codinghorror.com/blog/2005/05/on-managed-code-performance-again.html）はるかに少ない労力で、マネージコードでかなりまともなパフォーマンスを得たので、多くの場合、問題に見合う価値はありません。

3. 再利用性：安全でないコードは、完全信頼環境でのみ使用できます。たとえば、ASP.NETサーバーでは、バッファオーバーフローによる脆弱性の導入は非常に簡単であるため、通常、安全でないコードを使用することはできません。別の例はクリックワンスです。または、アプリケーションがネットワーク共有からアクセスされた場合。したがって、さまざまな展開シナリオでコードを使用することを計画している場合、安全でないコードはゲームから除外されます。

したがって、基本的には、不要なバグが発生する可能性があり、まったく利益が得られない可能性があり、コードの再利用性が低下するため、眉をひそめています。

しかし、シナリオが本当にパフォーマンスのためにそれを必要とする場合（そしてそれを証明するためのデータがある場合）、あなたは経験豊富なプログラマーであり、メモリーの処理方法を知っており、コードは制御された環境で使用されます。

ある意味で、アンマネージコードは支払い方法の1つです。追加の開発作業で、より高速な実行を購入できます。確かに、アンマネージコードは、開発、デバッグ、および保守にさらに多くの時間を必要とします。正確に理解することは、ほとんどの参加者にとって課題です。ある意味で、これはアセンブリでのプログラミングに似ています。確かに、アセンブリ^*で書き込むと、CPUからより多くの電力を奪うことができますが、そのルートに向かうより多くの労力を「費やす」ことになります。

時々、開発時間の違いは非常に重要です-時間ではなく日。ただし、実行速度の違いはそれほど劇的ではありません。そのため、アンマネージコードの開発は、投稿で説明したのと同様の状況（オーディオやビデオの処理など、リソースを大量に消費するアルゴリズムのローカライズされた自己完結型の実装）のために予約されています。

基本的に、あなたの質問に対する答えは、なぜ誰もがフェラーリを運転しないのかと同じです。それははるかに優れた車ですよね？（Un）幸いにも、誰もがそれを買う余裕はありません。

正確性や数学的な意味でのその他の制約について「確実」である（つまり、証明がある）ことは、命令型言語にとって非常に難しい問題だからです。多くの場合、プログラムには非常に多くの状態があり、考えられる各状態をチェックしても検証することはできません。また、建設的な証明の作成は、自動化できるものではありません。

したがって、その理由は、実行を管理することによって提供される保険が、安全でないコードで得られる小さなパフォーマンスの向上を上回ることが多いためです。もちろん、これは特定のユースケースにも依存します。

つまり、 C ++環境でプログラムのすべての作業と管理を妨げるものは何もありません。あなたはガベージコレクタなしですべてのメモリフープとリークを正しく管理できると確信しているので、C ++でそれを行うのは大歓迎です:)

逆に、C＃には、.NETフレームワークで安全に実行するための安全で管理された厳密に型指定された開発環境を提供するという利点があります。

アンマネージコードのプログラミングのバックドローは、開発時間が長くなり、詳細なテストのための時間が割り当てられることです。もちろん、処理速度が向上し、ソフトウェアの実行方法をより詳細に制御できます。

したがって、4.0から始まる.NET Frameworkでアンマネージコードを操作するオプションは、使用しないことで利益をもたらす可能性があることが確かな場合のエッジケースのオプションです...