3

「私たちプログラマー」が非プログラマーや管理タイプにとって単純だと考えるかもしれないいくつかのことを説明するのが難しい場合があります。

そう...

マネージ コード (または Java バイト コード) とアンマネージ/ネイティブ コードの違いを非プログラマーにどのように説明しますか?

4

10 に答える 10

11

管理されたコード == 「スタッフ全員またはバトラー、メイド、コック、ガーデナーが配置されたマンション ハウス」

アンマネージ コード == 「私が以前住んでいた大学の場所」

于 2008-10-30T22:48:34.990 に答える
3

私は、この議論から明らかになったことに驚いています (実際にはそうではありませんが、修辞的な意味で)。遅くなっても追加させてください。

仮想マシン (VM) とガベージ コレクション (GC)は何十年も前の2つの別個の概念です。ガベージ コレクトされたネイティブ コードのコンパイル済み言語が存在し、これらは何十年も前のものです (標準的な例: ANSI Common Lisp ; まあ、コンパイル時にガベージ コレクトされる宣言型言語 Mercury が少なくとも存在しますが、明らかに大衆は Prolog のような言語に対して悲鳴を上げています。 ）。

突然、GCed バイトコード ベースの VM は、すべての IT 疾患に対する万能薬になりました。既存のバイナリのサンドボックス(他の例はこちら、こちら、こちら)? 最小権限の原則 (POLA) /機能ベースのセキュリティ? スリムなバイナリ(またはその最新のバリアントSafeTSA )? 領域推定? いいえ、サー: Microsoft と Sun は、私たちがそのような倒錯について考えることさえ許可していません。いいえ、この素晴らしい (???) 新しい (???) 言語§/API 用にソフトウェア スタック全体を書き直したほうがよいでしょう。私たちのホストの 1 人が言うように、それは再び火と動きです。

§ ばかげてはいけない: C# が .Net/Mono を対象とする唯一の言語ではないことは知っています。それは誇張です。

編集：私が指摘したメモリ管理/安全性/コードモビリティの代替技術に照らして、S.Lottによるこの回答へのコメントを見ることは特に有益です。

私が言いたいのは、非技術者は、このレベルの詳細な技術に煩わされる必要はないということです。

一方、Microsoft/Sun のマーケティングに感銘を受けた場合は、だまされていることを説明する必要があります。GCed バイトコード ベースの VM は、彼らが主張するような目新しいものではなく、すべての IT 問題を魔法のように解決するわけではなく、これらの実装手法の代替手段が存在します (いくつかはより優れています)。

編集 2:ガベージ コレクションはメモリ管理手法であり、すべての実装手法と同様に、正しく使用するには理解する必要があります。ITA Software では、GC をバイパスして優れ​​たパフォーマンスを得る方法を見てください。

4 - 高速アクセスが必要な約 2 ギガの静的データがあるため、C++ コードを使用してポインタのない C 構造体 (フライト、運賃など) を含む巨大なファイルをメモリ マップし、外部データを使用して Common Lisp からこれらにアクセスします。アクセスします。構造体フィールドへのアクセスは 2 つまたは 3 つの命令にコンパイルされるため、実際にはパフォーマンスはありません。Lisp オブジェクトではなく C にアクセスした場合のペナルティ。これを行うことで、Lisp ガベージ コレクタがデータを認識しないようにします(Lisp にとって、C オブジェクトへの各ポインタはただの fixnum ですが、これらのポインタを Lisp オブジェクトで一時的にラップして、デバッグしやすさを改善することがよくあります)。したがって、私たちの Lisp イメージは、約 250 メガバイトの「動作する」データ構造とコードにすぎません。

...

9 - 800mhz のボックスで 10 秒間の Lisp 計算を実行でき、5k 未満のデータしかありません。これは、必要なすべてのデータ構造を事前に割り当て、それらを超えるクエリで終了するためです。これは多くの Lisp プログラマーをうんざりさせるかもしれませんが、250 メガの画像とリアルタイムの制約があるため、ガベージを生成する余裕はありません。たとえば、cons を使用する代わりに、"cons!" を使用します。これは、事前に割り当てた 10,000,000 個のセルの配列からセルを取得し、すべてのクエリをリセットします。

編集 3: (誤解を避けるために) GC はポインターを直接いじるよりも優れていますか? ほとんどの場合、確かに、両方に代わるものがあります。これらの詳細についてユーザーを煩わせる必要はありますか? 必要に応じてマーケティングの誇大宣伝を払拭する以外に、これが事実であるという証拠はありません.

于 2009-10-19T14:23:57.287 に答える
3

机について考えてみてください。定期的に掃除をしていれば、実際に作業しているものを目の前に座らせるスペースがあります。クリーンアップしないと、スペースが不足します。

そのスペースは、RAM、ハードディスクなどのコンピューター リソースに相当します。

マネージ コードを使用すると、システムはクリーンアップするタイミングと内容を自動的に選択できます。アンマネージ コードは、プロセスを「手動」にします。つまり、プログラマーは、いつ、何をクリーンアップするかをシステムに指示する必要があります。

于 2008-10-30T22:44:59.087 に答える
3

基本的な解釈は次のとおりだと確信しています。

  • Managed = ランタイムによって管理されるリソースのクリーンアップ (つまり、ガベージ コレクション)
  • 管理されていない = 自分で後片付けをする (つまりmalloc& free)
于 2008-10-30T22:47:00.593 に答える
2

おそらく、株式市場への投資と比較してみてください。

あなたは自分で株式を売買して、何が最高のリスク/報酬をもたらすかについて専門家になろうとすることができます - または、あなたのためにそれを行う「専門家」によって管理されているファンドに投資することができます - あなたの費用で一部のコントロールを失い、おそらく一部のコミッションを失います。(確かに、私はトラッカー ファンドのファンであり、株式市場の「専門家」は最近、まったく素晴らしい成績を収めていませんが....)

于 2008-10-30T22:50:00.137 に答える
1

アンマネージ コードは、コンピューターが従うべき命令のリストです。マネージ コードは、コンピューターのタスクのリストであり、コンピューターはタスクの実行方法を自由に解釈できます。

于 2008-10-31T00:00:41.040 に答える
1

これが私の答えです：

マネージド (.NET) またはバイト コード (Java) を使用すると、時間と費用を節約できます。

では、次の 2 つを比較してみましょう。

アンマネージド コードまたはネイティブ コード

独自のリソース (RAM / メモリ) の割り当てとクリーンアップを行う必要があります。何かを忘れると、いわゆる「メモリ リーク」が発生し、コンピュータがクラッシュする可能性があります。メモリ リークとは、アプリケーションが RAM/メモリを使い果たし (食べ尽くし)、コンピュータが他のアプリケーションに使用できるようにそれを手放さない場合の用語です。最終的に、これによりコンピューターがクラッシュします。

異なるオペレーティング システム (Mac OSX、Windows など) でアプリケーションを実行するには、オペレーティング システムごとにコードをコンパイルする必要があり、オペレーティング システム固有の多くのコードを変更して各オペレーティング システムで動作するようにする必要があります。

.NET マネージド コードまたは Java バイト コード

すべてのリソース (RAM / メモリ) の割り当てとクリーンアップが自動的に行われ、「メモリ リーク」が発生するリスクが最小限に抑えられます。これにより、リソース管理に費やす代わりに、機能のコーディングにより多くの時間を割くことができます。

異なるオペレーティング システム (Mac OSX、Windows など) でアプリケーションを実行するには、一度コンパイルするだけで、アプリケーションが (.NET Framework /モノまたはJava）。

要するに

.NET Framework (マネージド コード) または Java (バイト コード) を使用して開発すると、複数のオペレーティング システムを簡単にターゲットにできるアプリケーションを構築するコストが全体的に安くなり、メモリのありふれたタスクではなく、豊富な機能の構築により多くの時間を費やすことができます。 /資源管理。

また、.NET Framework が複数のオペレーティング システムをサポートしていないことを誰かが指摘する前に、技術的には Windows 98、WinXP 32 ビット、WinXP 64 ビット、WinVista 32 ビット、WinVista 64 ビット、および Windows であることを指摘する必要があります。サーバーはすべて異なるオペレーティング システムですが、それぞれで同じ .NET アプリが実行されます。また、Linux および Mac OSX に .NET を導入するMono プロジェクトもあります。

于 2008-10-30T23:22:40.337 に答える
0

それは、端に沿ってバンパーがある場合とない場合のプールのプレーの違いのようなものです。あなたと他のすべてのプレイヤーが常に完璧なショットをしない限り、ボールをテーブルに置いておくために何かが必要です。（意図的なリコケットは無視してください...）

または、サイドラインとエンドラインの代わりに壁のあるサッカー、バックストップのない野球、ゴールの後ろにネットのないホッケー、バリアのないNASCAR、またはヘルメットのないサッカーを使用してください...）

于 2008-10-31T01:30:29.923 に答える
0

大きな違いはメモリ管理です。ネイティブ コードでは、メモリを自分で管理する必要があります。これは困難な場合があり、多くのバグの原因となり、それらのバグの追跡に多くの開発時間が費やされます。マネージ コードを使用しても問題は残りますが、その数は大幅に減り、追跡も容易になります。これは通常、バグの多いソフトウェアが減り、開発時間が短縮されることを意味します。

他にも違いがありますが、メモリ管理がおそらく最大です。

彼らがまだ興味を持っているなら、バッファ オーバーランによるエクスプロイトがいかに多いか、マネージ コードではそれができないこと、コードの再利用が簡単になったこと、または COM を扱う必要がなくなったことについて言及するかもしれません (とにかく運がいい）。私はおそらく COM から遠ざかるだろう。

于 2008-10-31T00:02:58.210 に答える
-7

「マネージ コードという特定の用語は、Microsoft の世界で特に普及しています。」

私は MacOS と Linux の世界で働いているので、私が使用したり遭遇したりする用語ではありません。

Brad Abrams の「マネージ コードとは」というブログ投稿には、「.NET Framework 共通言語ランタイム」などの定義があります。

私の言いたいことはこれです: 用語を説明するのは適切ではないかもしれません. それがバグ、ハック、または回避策である場合、それはあまり重要ではありません。確かに、洗練された素人の説明を作成するほど重要ではありません. MS 製品のいくつかのバッチの次のリリースでなくなる可能性があります。

于 2008-10-30T22:43:14.610 に答える