私はずっと C++/CLI に興味がありました。たぶん、多くの開発者がそれを使用していないためです...または単に異なるためです.
Microsoft が VB.NET や C# (つまり、LINQ、WPF など) と同様に、C++/CLI を完全にサポートしているとします。使いますか?
そうでない場合、なぜですか?
私はずっと C++/CLI に興味がありました。たぶん、多くの開発者がそれを使用していないためです...または単に異なるためです.
Microsoft が VB.NET や C# (つまり、LINQ、WPF など) と同様に、C++/CLI を完全にサポートしているとします。使いますか?
そうでない場合、なぜですか?
私はそれを使用します。ツールのサポートが相対的に不足しているとはいえ、Win32 の処理に関しては生の P/Invoke より優れています。
LINQ に関して言えば、C++ 言語にこれ以上多くのハッキングが加えられるのはあまり気にしません。LINQ はそのままで十分に使用できます。コンパイラを拡張する場合は、C++ 0x サポートで動作するはずです...
適切な仕事に適切なツールを使用することがすべてです。マーシャリングを正しく行う方がはるかに簡単なので、プラットフォームの相互運用作業には C++/CLI を使用します。私は他のほぼすべての .NET 作業に C# を使用し、一部の VB.Net を使用しています (インライン XML が好きです)。確かに、IronRuby、IronPython、F#、またはその他の .NET 言語はまだ学んでいませんが、プログラミングの武器を増やすためだけに真剣に検討しています。
質問に答えると、私はそれが最も適した仕事にすでに使用していると感じているので、今まで以上に使用することはないと思います. 私が見る限り、C# は今でも最高の .NET 言語です。なぜなら、C# は古い言語を押し付けて適合させるのではなく、そのプラットフォーム用に特別に設計されたからです。C++/CLI のより良いサポートを追加しても、別の言語からの使用に影響を与えるのではなく、開発時間が短縮されるだけです。
C ++ / CLIは、マネージドコードとアンマネージドコードを統合するという約束を非常に効果的に実現します。これにより、完全にネイティブなC#ライブラリのように感じられるものを公開し、「内部」でネイティブC ++ /ライブラリに100%アクセスできます。それは優雅さの練習ではありませんが、実用的なプログラミングツールの歴史の中で何が比較されますか?
LINQとWPFが必要な場合は、C#を使用してください。これがC++/ CLIの優れた点です。マネージラッパーを作成してから、C#に戻ります。C ++ / CLIが日常的に使用するためにC#を置き換えることを意図しているのを見ていません。
...しかし、C# にはない C++/CLI の機能については、完全にはわかりません。-- @トーマス・オーウェンズ
(私の本の中で) 大きな利点の 1 つは RAII です ( .NET の RAIIに関する私の質問に対するAdam Wrightの回答を参照してください)。
おそらく...しかし、C#では提供されず、C++/CLIで提供されるものについては完全にはわかりません。おそらくポインタ?私はすべての .NET プログラミング (ほんの少しだけ) を C# で行い、F# を学び始めていますが、F# が完全にサポートされ、十分に文書化されていれば、もちろん試してみます。
巨大なランタイムに縛られたくないので、私はそれを使用しません。そして、私はこれらすべての^ポインターが好きではありません:)
ただし、.NET が提供する優れたライブラリが好き/恋しいです。
C++/CLI と MFC を組み合わせて WPF と XAML を利用していますが、新しい C++ 2008 機能パック (無料のリボン コンポーネント) を使用しています。:)
これを使用して、レガシー コードをサポートしたり、マネージ コードとネイティブ コードの間で shim を作成したりしています。VS11がそれをよりよくサポートしていることを愛しています