私は長い間 C# と .Net の開発者であり、C++ を学習するという考えに取り組んできました。
私がこれについて考えてきた主な理由の 1 つは、.Net フレームワークを使用するアプリよりも C++ の方がはるかに高速であるということです。しかし、Visual Studio で C++ アプリを記述したり、C++ アプリケーションで .Net ライブラリを参照したりすると、その C++ は (C# と同様に) MSIL に変換されるため、利点が失われると想定するのは正しいでしょうか。その中のコーディングから？
だから私の質問は本当にこれです..Netアセンブリを参照するアプリケーションのC++コンポーネントは、「従来の」方法でコンパイルされていますか、それともMSILにコンパイルされていますか?
まあ、それはそれよりも少し複雑です。.NET をサポートする C++ には、実際には 2 つのまったく異なるバージョンがあります。
Visual C++ 2002/2003 で使用できるオプションは、古いものである C++ 用マネージ拡張だけでした。新しいコンパイラでは、オプション /clr:oldSyntax で利用できます。標準の C++ との統合が難しいため、少しぎこちないため、すべての新しいキーワード (およびそれらの多くのキーワード) には、2 つのアンダースコアなどのプレフィックスが付けられます。ただ動作します」。
C++/CLI と呼ばれる新しい言語は、Visual C++ 2005 以降で使用できるクリーンな新しい言語です。最も重要なことは、コード生成のいくつかのモードをサポートしていることです。/clr オプションは、ネイティブ コードと MSIL コードの IJW 混合物を再び生成します。/clr:pure は、ネイティブ型を対応する .net 構造に変換する場合がありますが、マネージのみのアセンブリになります。したがって、コードはタイプ セーフではない可能性があり、/unsafe を指定した C# のようにポインター演算を使用できます。最も厳密なオプションは /clr:safe です。これは、C# コンパイラとまったく同じように (つまり、/unsafe なしで)、タイプ セーフで検証可能な MSIL のみのアセンブリを生成します。
MC++ と C++/CLI の違いについては、wikipediaを参照してください。
コンパイラ スイッチの説明については、MSDNを参照してください。
PS。.NET バイトコードは、MSIL (Microsoft Intermediate Language) または CIL (Common Intermediate Language) と呼ばれます。MIL は Media Integration Layer の略で、WPF と Vista Desktop Window Manager で使用される文書化されていない低レベル ライブラリです。
概念を分離しておくことはおそらく良い考えです。
まず、C++ は言語であり、対象となるプラットフォームについては何も指定していません。原則として、ストレートな C++ コードは、ネイティブの x86 アセンブラー、Java バイトコード、MSIL、または考えたいものにコンパイルできます。Adobe は最近、Flash バイトコードを生成する C++ コンパイラを作成したと思います。
2 つ目は、典型的な優柔不断さで、Microsoft は .NET を対象とした 2 つの C++ 派生言語を作成しました。まず、「C++ のマネージ拡張」を作成しました。それから彼らはそれがひどいと判断し、それを捨てて、それが存在しなかったふりをしようとしました.
現在、.NET スタイルの C++ の最善策は C++/CLI と呼ばれていますが、C++ ではありません。これは、多くの非標準的な方法で言語を拡張および変更します。(そして、C++ 標準委員会は、混乱を避けるために名前を変更するように要求したと思いますが、変更しませんでした)
Visual Studio 2005 以降では、C++/CLI がサポートされています。(「プロジェクトの追加」では、Visual C++ -> CLR の下にリストされています)
しかし(それほど単純だとは思いませんでしたよね?)、Microsoft は再びそれを行いました。C++/CLI を指定した後、実際には C++ を CLI に統合するためのかなり適切に設計された試みですが、事実上誰もそれを使用していないことに気付きました! C++ プログラマーでさえ、一般的に、.NET で作業するときは C# を使用し、それ以外の場合は適切なネイティブ C++ を使用することを好むことがわかりました。
そのため現在、ネイティブC++ と .NET 間の相互運用性をよりシンプルかつ強力にすることに注力しています。ただし、C++/CLI がなくなる可能性はありません。それは機能し、場合によっては便利です。彼らが最初に望んでいた C++ キラーではありません。
Visual Studio (これまでずっと) は、.NET によって汚染されていない、x86 マシン コードにコンパイルされたネイティブ C++ アプリケーションもサポートしています。これらは、Visual C++ -> Win32 の下の [プロジェクトの追加] ダイアログに一覧表示されます。
したがって、C++ を学習したい場合は、次の 2 つの選択肢があります。C++/CLI を学習します。MS 専用言語に制限されます。MSIL は、ネイティブ マシン コードではなく MSIL を生成し、.NET を実行する必要がありますが、通常はそうではありません。とにかく.NETに依存するつもりなら、C#で書いてみませんか？
または、.NET とは完全に分離されており、.NET アセンブリを直接参照できない適切な C++ を学習します。
重要なポイントは、それらが別々の言語であるということです。C++/CLI としてコンパイルする (つまり、コンパイラは .NET アセンブリを参照できるようになり、MSIL コードを生成する) か、C++ としてコンパイルします。この場合、.NET の世界は存在しません。
そして最後に注意事項です。上記の私の言い回し (「適切な C++」および「.NET によって汚染されていない」) にもかかわらず、C++ は「優れた」ものではありません。多くの場合、それも速くはありません。C++ はより高速になる可能性がありますが、それはプログラマーに大きく依存します。
C# コンパイラは、ほぼすべてのものを適度に効率的なコードに変換します。一方、C++ には、同等の C#よりもコードを遅くする落とし穴がたくさんあります。
http://blogs.msdn.com/ricom/archive/2005/05/10/416151.aspxおよびそれが参照するブログ投稿は、2 つの言語で記述された同様のコードのパフォーマンスに興味がある人にとっては一読の価値があります。
C++ アプリケーションが一貫して高速になる領域は 1 つだけで、それは起動時です。.NET アプリケーションは、.NET フレームワークをロードし、MSIL コードを JIT する必要がある場合があり、そこでネイティブ アプリケーションが開始されます。
しかし、それ以外では、C++ の方が高速であると想定するのはおそらく間違いです。それはあなたにもう少し制御を与えるので、そうすることができます。しかし、通常、これは、コンパイラがコード内で作成した非効率性からユーザーを救うことができないことを意味します。
これは、マネージドC++とアンマネージドC++についてのかなり良い（日付がある場合）議論です。
一言で言えば、C ++は管理（MILにコンパイル）または非管理（ネイティブコードにコンパイル）のいずれかです。
C++ を学びたい理由に関係なく、より多くの言語を知ることは常に良いことです。なぜなら、C++ を学ぶこと自体が貴重な教訓であり、視野が広がるからです。
C++ を使用すると、.NET アプリケーション C++/CLI またはネイティブとして実行できます。これは Visual Studio の単なるコンパイラ スイッチですが、この 2 つの間にはかなり多くの構文上の違いがあります。個人的には、両方のフレーバーを学ぶことは役に立つと思います。
プロジェクトでどちらを選択するかは、要件によって少し異なります。たとえば、プログラムが C# で記述されたモジュールなどの他のマネージド モジュールと対話する必要がある場合は、C++/CLI を使用して、マネージド コードとアンマネージド コードの間のオーバーヘッドの切り替えを回避することをお勧めします。
C++ コンポーネントは、.Net アセンブリを簡単に参照できません (COM を使用する必要があります)。Managed C++ は CIL にコンパイルされ、C# と同じパフォーマンス プロファイルを持ちます。
C++ は、ほとんどのコードで同じレベルの最適化で約 10% 高速ですが、C# は書き込みとデバッグに半分の時間がかかるため、同じ時間で、配置できる最適化により C# が高速になると主張します...