C ++ / CLI：なぜそれを使用する必要があるのですか？
私はC++にかなり慣れているので、.NETとその派生物（特にC＃）の学習を検討しました。
私がC++/CLIにぶつかった途中で、その言語に特定の用途があるかどうか知りたいですか？ネイティブC++からC＃に変換するための中間言語であると想定しているだけですか？
私の頭に浮かんだもう1つの質問は、.NET Frameworkにまだそれほど多くのプログラミング言語が存在するのはなぜですか？ （VB、C++/CLI、C＃...）
はい、C++/CLIは非常に具体的なターゲット使用法を持っています。言語（およびそのコンパイラー、とりわけ）は、アンマネージコードとの相互運用が必要なコードを非常に簡単に記述できるようにします。マネージ型とアンマネージ型の間のマーシャリングの組み込みサポートがあります。以前はIJW（It Just Works）と呼ばれていましたが、現在はC++ Interopと呼ばれています。他の言語ではP/Invokeマーシャラーを使用する必要があります。これは、C++/CLIでできることと比較して、非効率的で機能が限られています。
ネイティブC++、インスタンス関数を持つクラスと相互運用する必要がある場合、クラスのインスタンスを作成/破棄するためにnewおよびdeleteキーワードが必要な場合は、C++/CLIを使用するしかありません。 Pinvokeはそれを行うことができません。割り当てるメモリ量とインスタンス関数のthisポインターを正しくサンクする方法を知っているのはC++コンパイラーだけです。
.NETフレームワークには、C++/CLI、特にSystem.DataおよびWPFのPresentationCoreで記述されたコードが含まれています。管理されていない相互運用のニーズがない場合、またはレガシーコードベースで作業する必要がない場合は、C++/CLIを選択する理由がいくつかあります。 C＃またはVB.NETの方が適しています。 C++/CLIの機能セットは2005年頃に凍結されました。ラムダやLinq構文などの最近の追加はサポートされていません。また、IDEは、C＃およびVB.NET IDEで利用可能な多くの標準機能をサポートしていません。VS2010は、最初にC++/CLIのIntelliSenseサポートなしで出荷されることに注意してください。ちょっとしたキス-死のそこで。
更新：VS2012で復活し、IntelliSenseのサポートが復活しました。 C++でのWinRTアプリの作成を簡素化する言語拡張機能であるC++/CXのおかげです。構文はC++/CLIによく似ています。 Windowsフォームプロジェクトテンプレートは削除されましたが、デザイナーは引き続き機能します。 VS2012の新しいデバッグエンジンはC++/CLIをサポートしていないため、[ツール+オプション]、[デバッグ]、[全般]の[マネージ互換モード]オプションをオンにする必要があります。
最初のC＃は.NETの「派生物」ではありません。 .NETは言語ではなく、CLRに基づくアプリケーションフレームワークおよびクラスライブラリであり、そのために多数の言語が存在します。
とは言え、.NETを使用する最も説得力のある理由は、適切に設計されたクラスライブラリであり、Win32やMFCよりもWindows用に開発する方がはるかに簡単であることです。ただし、個人的には、古い言語の拡張機能を学ぶよりも、新しい言語を完全に学ぶほうがいいと決心しました。C＃は.NETで動作するように根本から設計されているため、.NETにはそれを選択することをお勧めします。
C++/CLIは、いくつかのレガシーコードで.NETを使用する場合に役立ちます。私は、WindowsフォームGUIを作成して既存のアプリケーションコードにそれらを接着するために使用しました。その他のraison d'etreは、単一のロードモジュールでマネージコードとネイティブコードの混在をサポートする唯一の.NET言語であるため、レガシーコードのパフォーマンスと再利用の両方に適しています。
言語の数に関しては、MicrosoftはすべてのWindowsアプリケーションが.NETに基づいていることを望んでいます。それは、OSのセキュリティと安定性のために優れているからです。その唯一の方法は、複数の言語をサポートすることです。 .NETをアプリケーションプラットフォームまたはOS APIとして考えてみてください。どのプラットフォームにも多くの言語があるのと同じ理由で、.NETには多くの言語があります。これらの理由は、商業上の利点、アプリケーションの適合性、政治、既存の開発者のサポート、選択など、多くの理由があります。
マイクロソフトはこれについての立場を数回変更しました。 元々は本格的な言語として意図されていたものであり、本質的にすべてのネイティブ開発者がネイティブC++を放棄して移行することを望んでいたものです。
それから数年前、彼らはこれは単に顧客が望んでいたものではないことに気づきました。とにかく.NETに移行している開発者は通常C＃のような言語にジャンプし、残りはkeepネイティブの世界でコードを使用する理由があるため、C++を使い続けます。
したがって、Microsoftは現在、C++/CLIがネイティブC++コードと.NET言語で記述されたマネージコードとの間の「橋渡し」になることを意図しています。コードベース全体の切り替え先として推奨される言語ではなくなりました。
実際、これは主に、.netコードをネイティブのアンマネージC++に簡単にリンクするための中間言語として意図されています。自分に有利なことをしてください。必要がなければ、使用しないでください。 C++/CLI構文は混乱しています。
2番目の質問について...今日、C＃が.netの主要言語であると思いますが、誰もがそのスタイルとパラダイムを好むわけではありません。 .netのアーキテクチャにより、新しい言語を簡単に追加できます（関数プログラミングを目的としたF＃を参照）。
C++/CLIを使用して、一部のアンマネージC++ライブラリ用の.NET APIを作成しました。パラメータの受け渡しとマーシャリングにはある程度慣れる必要があります（使用する型によって異なります）が、慣れてきたら、管理された世界と管理されていない世界のギャップを埋めるのにとても良い方法です。
私はC++/CLIを見ていませんが、それは.NETの世界を利用しています。これは、C++とC＃の中間にあり、両方の世界で最高のものを持っていると考えてください。 .NETオブジェクトに簡単にアクセスできるC++とそのコアBCLを使用したい場合に役立ちます。これを見てください 記事 C++/CLIの入門について議論しています。残念ながら、マネージドC++アプリケーションは、構文の面で多くのC++の友達を混乱させ、アンマネージドC++の世界に戻ってきたフォロワーの集まりを失ったため、聞いたことがありません。
よろしくお願いします、トム。
私にとっては、c ++クラスを再利用する方法が他にないときに使用する必要があります