C ++ MFC vs .NET？
私の同僚はVisual Studio 2002を使用しており、C++ MFCを使用しています。私はC＃で開発しています。
以前は何の問題もありませんでしたが、今では本当に異なる環境で開発すべきかどうかをお客様に質問しています。私の同僚は（もちろん）C++ MFCに移行すべきだと考えています。 MFCの代わりに.NETを使用できると思います。
MFCを学習するポイントはありますか？少し時代遅れに感じますか、それとも間違っていますか？ MFCと比較した.NETに対する、および.NETの議論は何ですか？
編集：
原子力産業向けのプロセスシステムと支援アプリケーションを開発しています。メインアプリケーションは、古いコンピューターシステムをエミュレートし、C++/MFCを使用するエミュレーターです。これは非常に時間が重要であり、おそらくコアがネイティブC++のままである必要があります。しかし、エミュレーターとすべての周辺アプリケーションのGUIは特に重要ではありません。
また、既存のMFCアプリケーションを置き換える必要がある本当の理由はありますか？
MFCとWindowsフォームの両方を非常に長い間使用しています。私はビデオゲーム業界の出身なので、長年にわたって多くのデスクトップアプリケーションを作成する必要があり、.net以前は、MFCは非常に便利でした。その前でさえ、私は純粋なWin32でツールを書いていました。
MFCには間違いなく癖がありましたが、全体的には生活がずっと楽になりました。 OpenGLとDirect3Dをカスタムビューに統合するのは非常に簡単でした。そして、いったん慣れてしまえば、カスタムコントロールの作成は簡単なことでした。何よりも、純粋なC++でコーディングすることができたので、たまたま自分の選択した言語になりました。さらに、MFCは非常に効率的でスナッピーであることがわかりました。
MFCは徐々に外部制御ライブラリのサポート、特にドッキング/ツールバーライブラリの取得を開始しました。そのため、3Dモデルビューアーやレベルエディターなどの私のツールはすべて非常にきれいに見えました。
私が書いたほとんどのアプリケーションはプログラムでUIを作成したので、ダイアログ/ウィンドウレイアウトツールは私のニーズに十分すぎるほどでした。
MFC 9も、特にMicrosoftがFeature Packの一部としてリリースしたリボンコントロール/ドッキングライブラリを使用すると非常にクールです。ですから、老犬にはまだ生命があります。 :)
.net 1.0がリリースされたとき、マネージドC++をサポートしていたため、移行はかなり簡単でした。それはきれいではありませんでしたが、.netフレームワークに比較的簡単なオンランプを与えました。しかし、私にとっての転換点は、.NET 2.0の頃に、Windows Forms Designerをさらに必要とするツールを書き始めたときでした。私はもう一度始めて、大好きなC＃を学ぶことにしました-しかし、delete（）なしでnew（）を持つことに慣れることは決してありません;）。その後、ユーザーコントロールの作成を開始し、エクスペリエンス全体を非常にわかりやすくわかりやすくしました。 .netフレームワークは巨大であり、十分にサポートされており、一般的にC＃/。netのほとんどすべてを簡単に実行できることがわかりました。さらに、コンパイルは非常に高速で、Visual Studioでリファクタリングする機能は素晴らしかったです。
C＃/。netの素晴らしい点は、マネージコードを記述するだけではないことです。たとえば、パフォーマンスが問題になる場合、またはプラットフォーム間でコードを共有する必要がある場合は、アンマネージコードを使用できます。たとえば、私の数学ライブラリはC/C++で書かれており、C＃が同じコードをラップ/使用できるようにするライブラリに入れていますが、これは一時的なものです。これらのライブラリもC＃に時間内に移植するので、すべてが.netになります。
私が言及したい最後の経験は、私がコンソールゲームプログラミングから過去数か月を費やし、InterWebのプログラミングに時間を費やしてきたことです。 ASP.net/C#でプログラミングしているMicrosoftスタックを使用してきましたが、C＃のすべての知識を直接適用できる、非常に優れていると言わざるを得ません。唯一の学習曲線はASP.netであり、言語およびサポートライブラリではありません。 .net 3.5（LINQは甘い）の登場により、C＃を使用した.netフレームワークでの生活は素晴らしいものになりました。
とにかく、これを私の人生の物語に変えたくはありませんが、あなたが尋ねてきたすべてのテクノロジーを乗り越えた人の短い経験をしたかっただけです。また、さまざまな言語/フレームワークを試してみるのも良いことです。私はもう1年iPhoneのコーディングを行ってきましたが、Objective-Cが本当に好きになりました。それはすべてプログラミングであり、すべて良いです。
MFC/.netに関しては、どちらにもプラスとマイナスがあり、MFCはまったく気にしませんが、前進するという点では、おそらくC＃/。netに固執しますが、どうか、お願いします、お願いします仕組みを理解します。私が言う唯一の説教的なことは、「それはすべてあなたのために世話をしています」にもかかわらず、.netのメモリがどのように機能するかを理解することです;）
C/C++の知識は、MFCを使用するかどうかに完全に依存する必要がありますが、依然として重要な言語（特にコンソールベースのビデオゲームプログラミング）ですが、Windowsでのデスクトップアプリケーションプログラミングでは、議論するのがますます難しくなっています。ネット。高速、簡単、優れたツールサポート、優れたサードパーティライブラリ、巨大な成長コミュニティ、クロスプラットフォーム（Mono）になり、現在のすべてのMicrosoftテクノロジー（ASP.net、WPF、Silverlight、WCF）の間を移動できるようになります。等）。
ただし、これらすべてのために、Visual StudioをC++環境としてセットアップしました。一部の習慣は決して死なない;）
MFCと.NETはほぼ正反対の両極端であり、それぞれ独自の方法で徹底的にくだらない。
MFCの使用は、大体、第二次世界大戦の余剰ビルの崩壊した大破に住んでいます。危険なエリアについて警告する兆候はありません。また、流水、電気、または機能するトイレをどこで見つけることができるのかすぐにはわかりません-それらのすべてがそこにあるとしても、それらを見つける方法を知っていれば。老朽化した建物のように、壁などにたくさんの穴がありますので、いつでも好きなだけ離れることができます。同様に、外の世界から物をドラッグするのは非常に簡単ですが、そこに到達するために「ドラッグ」を行うのはあなた次第です。
.NETを使用することは、The Truman Showのセットで生活するようなものです。それは、実際の生活べきがどのようなものであるかの一人の考えに適合します。その境界内で、人生はユートピアのように見えます。しかし、結局のところ、それは愉快な装身具の刑務所に過ぎず、人生として描かれているものはまったく現実的ではありません。外の世界とのあなたのすべての相互作用は、主に自分の評価を改善することを目的とする監督の気まぐれに左右されます。あなたの福利厚生は彼に影響を与える範囲でのみ考慮されます。
ほとんどの刑務所とは異なり、.NETにはよくマークされたエスケープルート（「P/Invoke」というラベル）があります。しかし、良い刑務所からの脱出ルートのように、それはマイルの長さの下水管です。ほとんどの住民はその存在を知っていますが、そこに行くのはほぼ唯一、男らしさを証明するティーンエイジャーです。それを実際に使用する少数の人は、非常に必要な場合にのみそうします。一度必要だと思った私たちは、外に出ずに戻ってこない方が良いと気づきました。
編集：一部の人々は、円と矢印、およびそれぞれの裏にある段落を法廷で証拠として使用したいので、MFCの長所と短所は、ほとんどがAPIの薄いラッパーであることです。カバレッジにかなりの数の穴があり、API自体が特にうまく適合しない場所を「滑らかにする」ことは比較的少ないため、これは弱点です。たとえば、COMを使用して実装されたものは、通常それを使用するコードに直接表示されます。これは強みです。MFCを拡張して、既定ではない領域を処理し、必要に応じてAPIを直接操作するだけでなく、MFCを簡単に拡張できるためです。また、比較的頻繁に更新されないため、現在は適度に「モダンな」アプリケーションを作成できますが、常にそうであるとは限りません。その歴史を考えると、今後もそうであると予測するのは難しいでしょう。
.NETの長所と短所は、APIの「より厚い」ラッパーであることです。 APIの違いを「スムーズに」するためにかなり多くのことを行うため、（たとえば）COMで実装された部分は、まっすぐなC関数呼び出しとして実装された部分とは見た目も動作も著しく異なりません。 .NETの内部から、違いは消えます。 .NETは（現在）Microsoftの好むテクノロジーであるため、はるかに定期的に更新されており、UIが最新のガイドラインに従っていることを確認するためのはるかに良い仕事をしています。私の推測では、MFCよりもしばらくそうする可能性がはるかに高いと思われます。
.NETの弱点は、バイパスまたは拡張がはるかに難しいことです。基本的に、外の世界への唯一のルートはP/Invokeを経由することです。ちょっとした小旅行でも、くて苦痛です。非常に頻繁に、または主要な拡張に近づいている何かのためにそれを使用しようとすると、マゾヒズムの練習です。
（ほぼ）作成するすべてが.NETがサポートするものに収まる場合、それは明確な選択です。境界内にいる限り、ずっときれいで滑らかです。
フレームワークでサポートされている範囲をかなり頻繁に超える必要があるコードを記述する場合、MFCはおそらくはるかにうまく機能します。 .NETでは、.NETモデルはwholeプログラムに適用されます。 MFCを使用すると、UIにMFCを使用するプログラムを比較的簡単に作成できますが、MFCがサポートしていない他のすべての処理を実行できます。
この言語は長い間使用されるため、C++を知ることには価値があると思います。 C++でのプログラミングがいつ必要になるかはわかりません。今日の雇用市場では、より多くの言語を使用することで履歴書が強化されるだけです。
[〜＃〜] mfc [〜＃〜] に関しては、そこから抜け出すために最善を尽くしています。コンピューティングの標準では古い（20年近くになると思います）が、Microsoftは新しいリリースや機能パックでサポートすることの価値を認識しています。その観点から、MFCがすぐになくなるとは思わない。しかし、それは私がそれでプログラムしたいという意味ではありません。 C＃でプログラムできる流動性と使いやすさは、毎日MFC/C++を圧倒しています。スレッド、ソケット、文字列操作など-これらすべてのことは、C++よりもC＃の方が簡単です。さらに、C＃/。NETはMicrosoftの主要なテクノロジーフォーカスであり、キャリア開発に関しては、MFCバックバーナーよりもそのエッジになりたいです。
解決しようとしている問題は何ですか？ C++/MFCとC＃/。NETの両方を等しく知っているとします。どのツールセットを使用すると、構築と保守が改善されますか？ （より良いのは主観的ですが、これもあなたの目標に依存します）
.NETで使用できないネイティブAPIで多くの作業を行っているのでない限り、.NETを使用します。 C++は優れた言語であり、.NETフレームワークとメモリ管理を維持するためにManaged C++でのコーディングを妨げるものは何もありません。
比較すると、MFCフレームワークは、.NET Windowsフォームと比較して非常に面倒で扱いにくいです。
MFCが提供するすてきな機能の1つは、ドキュメント/ビューフレームワーク（単一ドキュメントまたは複数ドキュメント）です。この機能は、MicrosoftのWordのように機能するアプリケーションを作成する必要がある場合に非常に便利で便利です。ユーザーに表示したいビューからデータモデルを分離するのに役立ちます。この機能が実装されれば、ほとんどの人は.NET側に飛ぶと思います。 （Microsoftはこれに取り組んでいますか、少なくともこれに取り組む予定はありますか？）
どちらか一方ではありません。バージョン1.1以降、Windows Formsは、IEまたはMFCダイアログなどのネイティブクライアントによってホストされることをサポートします。MFC8.0は、Windows Formsサポートクラスで必要なホスティングコードをラップしました。現在のプロジェクトの要件に基づいて適切なライブラリを選択します。
MFCは、そのGDI=ラッパークラス以上のものです。かつては、現在の.Netによく似た、基礎となるWin32 APIのOOP置換として設計されました。 。しかし、MFCはWin32 APIの成長を止めなかったため、Win32 APIはMFCがサポートできる範囲を超えて成長したと言えますが、過去10年間でAPIの数は数十倍に増加しました。
一方、Windows Formsは、WindowsのGDIシステムのみを置き換えるものでした。WPFなど、Win32の残りの部分を置き換えるための残りの.NET Frameworkライブラリです。 DirectXのXNAおよびSAPIのSystem.Speechただし、Win32 APIは、数年でダウンロードサイズを大幅に追加することなく、.Netが維持できる範囲を超えて成長することがわかります。
したがって、Windows FormsはMFCが実行できるすべてを実行することはできず、GDI +ベースのRADを容易にし、MFCが実行できないものを含めることができます。 MFCは消費者の要求に基づいて復活しましたが、将来のアプリケーション向けに設計している場合は、それを考慮することをお勧めします。
私はC++/MFCからC＃/ WinFormsに1年以上前に移行しました（後期のブルマー、私は知っています;））。
言語の違いはさておき、MFCからWinFormsへの移行は、他の方法よりもはるかに簡単になります。レガシーアプリケーションの保守に効果的に取り組むつもりであれば、MFCを知ることには間違いなく価値があると思います。しかしながら：
MFCをゼロから学習しますか（既存のテクノロジが与えられた場合）？いいえ、おそらくそうではありません。
MFCで新しいアプリケーションを作成しますか？いいえ、おそらくそうではありません。
MFCの利点は、.NETのサポート、柔軟性、および使いやすさがはるかに重要です。それが何であるかについて、MFCは素晴らしいです、そして、それで働いた機会に感謝しています-それは私にlotを教えました。しかし、最終的に、それは出て行くところにあります。
この選択には多くの賛否両論があります。 MFCは古いスタンドバイであり、長年使用されており、その年齢を示しています。一方、それはまだかなりサポートされており、MSは最新の状態を維持するために更新を続けています。
.Netフレームワークは、それを支援する大規模なチームを持ち、Windowsの新しい部分を構築するものと見なされているため、より良いサポートを提供します。
一方、MFCはWindowsエコシステムの大きな部分を占めています。プラットフォームでプログラミングしている場合は、少なくともMFCが何をしているのか、MFCアプリをサポートするようになったら（そしていつかは心配しないでください）の実用的な知識があれば価値があります。どこから始めればよいのかを十分に把握してください。
アンマネージコードは必ずしも高速で実行されるとは限りません。記述されたコードとコードを記述したコードに依存します。いくつかの洗練されたベンチマークレポート（ソース、コードプロジェクト）を読みましたが、C＃はいくつかの点でC++を打ち負かし、C++は他の点で勝ちました。それはあなたの分野に依存します。私はFlight Simulator用のソフトウェアを書いているので、管理されていない環境が必要です。 GUIアプリケーションを作成する場合は、C＃の方が適している場合があります。ローレバーソケットプログラミングの場合、C++はより良い結果を返す場合があります。通常の操作ではC++とC＃の間に重大な速度の違いはありませんが、ネイティブポータビリティとC＃の使いやすさでC++のファンです。