C++ にこだわる者として、これは本当に私を悩ませてきました。私は、Microsoft が約 10 年前に思いついた「言語に依存しないフレームワーク」のアイデアを常に気に入っています。なぜ彼らはこのアイデアにボールを落としたのですか? その背後にある理由を知っている人はいますか?
4 に答える
その理由の一部は、C++ サポートが実際には 1 つに 2 つの言語、つまりネイティブと CLI バリアントであることです。その余分な開発負荷は、適切な MSBuild 統合が他の言語よりも遅れた (ラグ? 2008 年以降は確認していません) 理由として、Visual C++ チームによって認識されています。
もう 1 つの部分は、バインディングの「魔法」などをサポートするために C# ビルドで行われるコンパイル中のコード生成です。F# であっても、「ちょうど起こっている」とは言えないことがわかりました。
私の場合、GUI の作成に C++.Net を使用すべきではないというのが私の推論です。
私はここで意地悪をしようとしているわけではありません。誰かが私のやり方の誤りを教えてくれるかもしれませんが、それは良い考えだとは思いません。私は今それをいじっていますが、アプリケーションが C# で記述されていた場合よりも開発がはるかに遅くなります。アプリケーションに C++.Net または通常の C++ の機能が必要な場合は、面倒な作業を行い、C# とインターフェイスできる DLL を作成することをお勧めします。
もし彼らがそれをサポートしていれば、基本的にすべてを C# で書き直すよりもはるかに簡単かつ安価に、C++ コードを新しい GUI に移行できたはずです。アプリを作り直すのに大金がかかりました。これは、まさに不況の中で望んでいたことです。
その理由は、C# が普及している (そして C++ ほどクロスプラットフォームではない) ため、開発作業を必要最小限に留めることに決めたからだと思います。
マネージC++でWPFを実行できます。
その理由は、ほぼすべての新しいアプリケーションプログラミングが、JavaScript、Java、VB.NET、またはC#(すべてのGC言語)で行われるようになったためです。スキルセットが低くても品質が高いことに重点が置かれ、C ++は開発者に過度の要求をします。企業は、初日にログバグコードを記述してほしいと考えています。
アプリケーション用のC++は、主に既存のアプリケーションの保守用、または極端なパフォーマンスが必要な場合に使用されます。デバイスドライバーとOSは依然としてC++で頻繁に記述されていますが、それでも変更されています(CoyotosはCbit、E#、Cosmos / MosaはC#、Singularity / Midoriです)。