2

特定のシナリオで使用するのが望ましい言語は常にあります。迅速なプロトタイプ開発のために、VB6 は当然の選択でした。VB6 は、シンプルなデスクトップ ユーザー インターフェイスと、標準的で単純なデータベース操作の要件を備えたプロジェクトで選択されました。低レベルのルーチンを使用してデバイス ドライバーを開発する場合は、おそらく C または Visual C++ に依存していました。ASP は、Web インターフェイスの開発の標準的な選択肢でした。大雑把に言えば、すべての言語には特定の「ドメイン」または「専門化」がありました。

.NET フレームワークでは、すべての言語が相互運用可能であり、おそらく一貫性があります。さまざまな言語のモジュールをまとめてプロジェクトに含めることができますが、最終的にはすべて同じように扱われます (すべて IL にコンパイルされます)。

これは、私たちが以前持っていた区別がもはや存在しないことを意味しますか? その差別化は必ずしも悪いものではなく、何らかの制約によるものではなく、設計によって存在していたものです。これは、.NET フレームワークとそのさまざまな言語の処理により、明らかにいくらか減少しています。

4

5 に答える 5

7

区別はまだ存在します。たとえば、VB.NET は現在、C# (C# 4.0 を除く) よりも優れた方法で IDispatch レイト バインディングをサポートしており、VB.NET にはコードとインラインの XML リテラルがあり、他の .NET 言語と比較して XML を操作するための便利なツールとなっています。C++ は、C++/CLI バリアントを使用しても .NET にはあまり適していない傾向がありますが、(いつものように) ネイティブ プログラミングや、マネージ コードとアンマネージ コード間の相互運用層の提供には優れています。

すべての言語には、特定の概念をより簡単に表現できるようにする構文のニュアンスがあります。それらがすべてILに煮詰められたとしても、それらがすべてアセンブリに煮詰められたときと同じです。コンパイル先のプラットフォームに関係なく、実行しようとしているタスクを最もよくサポートする構文の言語を選択します。

于 2008-10-29T19:10:20.783 に答える
6

言語の違いはそのままです。言語をアセンブリ コードにコンパイルするか MSIL にコンパイルするかは実際には違いはありませんが、MSIL の抽象化レベルがアセンブリの抽象化レベルよりも高い可能性があることを除きます。

.Net の大きな利点は、言語 3 で書かれたアプリケーションによってリンクされた言語 2 で書かれたライブラリで、言語 1 のオブジェクト コードを使用できることです。

はるか昔、電気や自動車が登場する前は、C で生成された .obj ファイルを Pascal または Delphi アプリケーションで単純に使用することはできませんでした (その逆も同様です)。メソッドとパラメーター シーケンスおよびパラメーターの互換性)、または別の実行可能ファイルの呼び出し。

于 2008-10-29T19:20:43.367 に答える
3

いいえ、フレームワークの機能は言語機能と同じではありません。.Net によって言語間の区別が取り除かれたと言うのは、アセンブリ コードによって言語間の区別が取り除かれたと言うようなものです。

言語にはまださまざまな機能があり、一部の言語の構文は一部の問題を解決するのに適しています。そうしないと、.Net フレームワーク全体が単一の言語で均質化されます。

于 2008-10-29T19:10:53.573 に答える
2

どちらかといえば、相互運用性が非常に高いという理由だけで、言語間の差異が高まったのではないかと思います。現在、言語に焦点が当てられています。

同じ基本サービスと基底クラスが利用可能であるということは、言語と提携しているフレームワークが提供するものではなく、言語が提供するものに基づいて、言語について賢明な決定を下せることを意味します。

たとえば、レイト バインド COM を操作する場合、(しぶしぶ) VB を選択する場合があります (または、C# 4.0 を待つ場合もあります)。特定の金融/シミュレーション作業については、F# について真剣に考えるかもしれません。通常のビジネス プログラミングでは、私は断然 C# を選択します。

ただし、さまざまなブロックに適した言語に基づいてこれらの選択を行い、さまざまな言語のさまざまな dll から完成したアプリをまとめることができます。以前は、コードの残りの部分と相互運用するために言語xを使用する必要があったため、コードの一部と戦わなければならなかったかもしれません。

于 2008-10-29T21:17:03.647 に答える
0

それは、質問が尋ねられた文脈に本当に依存すると思います。

顧客が使用するライブラリを開発しているとしましょう。このアセンブリをCLSCompliant属性でマークします。これは、コンパイラが CLR によって保証されている機能を使用することを強制し、言語固有の機能を使用するとコンパイルに失敗することを意味します。

CLS 準拠のライブラリが検討されている場合、.NET は言語間の区別を取り除きます。すべての .NET 言語は CLS に準拠する必要があるため、すべての .NET 言語を同等にサポートすることが保証されます。

ここで、ライブラリを VB .NET で作成していて、メソッドのオーバーロードではなくオプションのパラメーターを使用することにしたとします。この場合、オプションのパラメーターは CLS に準拠していないため、.NET は言語間の違いを強調しています (ただし、C# は .NET 4.0 でそれらをサポートしているようです)。オプションのパラメーターをサポートしていない言語を使用している場合は、ライブラリが不可能か、せいぜい使いにくい。各言語には、CLS に準拠していない機能がいくつかあります。これらを使用すると、一部の .NET 言語のユーザーがライブラリを使用するのが難しくなる可能性があります。

だから、ひっかけ問題のような気がします。CLS 準拠のコードを記述している場合、.NET 言語間の違いは構文だけです。そうでない場合は、一部の .NET 言語では使用できないメソッドを作成できる可能性があります。

于 2008-10-29T21:33:57.607 に答える