私はMFCの大ファンではありませんでしたが、それは本当の意味ではありません。Microsoftが2010年にMFCの新しいバージョンをリリースする予定であり、それは本当に奇妙なことに私を驚かせたと読みました-MFCは死んでいると思いました（悪意はありません、私は本当にそうしました）。
MFCは新しい開発に使用されますか？もしそうなら、どのようなメリットがありますか？私はそれがC＃のようなもの（あるいは単にWin32APIを使用するc++）よりも利点があるとは想像できませんでした。
17553 次
8 に答える
25
MFCを使用したコードはたくさんあります。私はこれらの質問をいつも見ていますが、これはまだ使用されていますが、答えはイエスです。私は非常に大規模な組織で働いており、まだCOBOLで書く何百人もの人々を雇用しています。企業で使用されたことがある場合は、それをサポートするハードウェアがなくなるまで使用され続けます。古いコードが引き続き機能するように、エミュレーターを作成するために誰かにお金を払う会社もあります。
海軍は今でもメモリ用の磁気コアを備えたコンピュータを搭載した船を使用しており、彼らにはそれらに取り組む人々がいると確信しています。一度作成されたテクノロジーはサポートできません。大規模な組織がシステムの機能を完全に理解しておらず、企業を屈服させることへの恐れを最優先に感じているDeus ex machinaの場合は少しですが、新しい技術を試してみたいとは思っていません（BTW OS2でのベストエフォートサポートに対してIBMに支払います）。
また、mfcは、ほとんどの人が.netから取得するほとんどすべてのシステムAPIをラップするオブジェクトモデルであるため、Windows開発に完全に受け入れられるソリューションです。
補遺として、そしてこの質問は賞金のためにあるので、これはVS11のmfcに関するMSからの引用です
すべてのリリースで、製品のさまざまな領域にわたって投資のバランスを取る必要があります。ただし、MFCは、ネイティブデスクトップアプリケーションを構築するための最も完全な機能を備えたライブラリであると私たちは信じています。私たちは、MFCを高レベルの品質でサポートおよび維持することに全力で取り組んでいます。VisualStudio11のMFCで修正したいくつかの問題の短いリストを次に示します。
投稿全体を読みたい場合は、こちらのリンクをご覧ください
于 2010-02-16T02:13:36.177 に答える
21
涼しさは、新しいシステムのテクノロジーを選択する際には考慮されません。はい、学生の場合、または遊んでみたい場合は、好きなものを選択してください。
しかし、現実の世界では、各テクノロジーには長所と短所があります。1年前、チームの1つが新しいプロジェクトを開始し、MFCで実行することが決定されました。理由は非常に単純です。プリンター、Internet Explorerでの低レベルの操作には、Windows APIを頻繁に使用する必要があり、神は他に何を知っていますか。
C＃はゲームにも含まれていませんでした。どちらも必要な機能を備えており、どちらも低レベルの機能を簡単に統合できました。唯一の違いは、一部のチームメンバーがすでにMFCの経験を持っていたため、そうではなかったということです。トレーニングで時間とお金を無駄にする必要があります。
彼らがC＃とWPFを選択したとしましょう。
-1すべてのネイティブC ++およびASMコードをDLLでラップする必要があります（ラッパーを作成するコーディングの代わりに、これは面倒な場合があります）。
-1おそらく、2つのチームが必要です。1つはUI用、もう1つはwinapi用です。多くの人がC＃とwinapiの両方を書くことができるとは思えません。どちらの方法でも、インターフェイスをきれいにするために誰かが必要であることに同意しました（プログラマーは通常これを嫌い、コストがかかります）が、少なくともC ++のみのコードでは、2つのチーム間の待ち時間はなく、UIの変更が必要です、問題ありませんUIデザイナーを待つ必要はありません、彼はかなり後でそれを作ります。
+1 UIコードはC＃とWPFで記述できます。たとえば、UIの開発は高速ですが、UIはプロジェクトの1/4にすぎません。
-1パフォーマンスの低下：C＃で実行できない小さな操作ごとに、外部DLLを呼び出します（プログラムは8GB RAMクアッドコアで実行されるため、これは小さな問題です）。
結論として、MFCは、要件とコストによってプロジェクトのテクノロジが決定されるため、新しい開発に引き続き使用されます。場合によっては、MFCが最適であることがあります。
于 2012-05-05T18:40:36.120 に答える
14
MFCは、まだいくつかの新しい開発、および多くの保守開発（Microsoftの内部を含む）に使用されています。
Win32 APIを直接使用するよりもわずかに遅くなる可能性がありますが、パフォーマンスの低下は実際にはごくわずかであり、全体のパーセントになることはめったにありません。.NETを使用すると、パフォーマンスの低下がかなり大きくなります（私のテストでは、10％未満になることはめったになく、20〜30％が一般的で、重い計算の場合はさらに高くなります。たとえば、固有ベクトル/固有値の計算を行うプログラムがあります。かなり大きなアレイで。C++とMFCを使用した元のバージョンは、標準のテストマシンで1分足らずで1つのテストケースを実行します。同僚の何人かは、C＃で再実装するのがクールだと判断しました。バージョンには約3分かかります。同じマシン上（クアッドコア、16ギガのRAMなので、「レガシー」ハードウェアではありません）。私は彼らのコードをあまり詳しく調べていないことを認めます。改善されるかもしれませんが、彼らはまともなコーダーなので、3：1の改善はありそうもないと思います。
MFCを使用すると、フレームワークをバイパスして、必要に応じてWin32APIを直接使用することも簡単にできます。.NETを使用すると、そのためにP / Invokeを使用できますが、比較するとかなり苦痛です。
于 2010-02-16T05:37:39.123 に答える
8
MFCは、VisualStudioのリリースごとに更新されています。見出しの機能項目ではありません。
新規開発に関しては、はい。それはまだ使用されており、今後も使用され続けます（私はあなたのように、使用したくないのですが）。多くの組織は何年も前にテクノロジーの決定を下し、変更する理由はありません。
でも、老舗のお店のことを言っていると思いますが、最先端にとどまるのではなく、書かれたものを維持・強化することに関心のある人たちです。
于 2010-02-16T02:10:36.893 に答える
8
MFCフィーチャーパックのリリース（1、2年前、iirc）は、約10年以来のMFCの最大の拡張であり、MFC開発にまったく新しい後押しを与えました。多くの企業が、レガシーアプリケーションを維持し、それらを前進させ、それに基づいて新しいアプリケーションのレベルを下げることに決めたと思います。
私にとって（大規模なMFCアプリケーションを維持する必要がある人として）、より大きな問題は、MFC自体ではなく、（Microsoftおよびサードパーティの）コンポーネントの開発とサポートが減少していることです。たとえば、サポートされていない古い純粋な32ビットActive-Xコンポーネントがアプリケーションで多数組み立てられている場合、64ビットへの移植は容易ではありません。
于 2010-02-16T19:54:41.930 に答える
3
私は昨年、MFCに基づいたプロジェクトを行いました。MFCが選択された理由はわかりませんが、1990年代半ばにさかのぼるwin32ベースのPCで毎秒10フレームのリフレッシュレートで効率的に実行される仮想3Dグラフィックユーザーインターフェイス（ビル管理セキュリティシステム）を作成するには十分でした。 。実行可能ファイル（コアwin32システムDLLのみを必要とする）は400K未満であり、最新のツールでは簡単に実現できません。
于 2010-02-16T02:02:40.013 に答える
2
マネージコードから離れることには利点があります（ドライバーUIを作成している、またはCOMを実行している可能性があります）。
それとそこにたくさんのMFCコードがあります。たぶん、あなたはX社で働いていて、過去12年間に彼らが書いてきた無数のDLLの1つを使用する必要があります。
于 2010-02-16T02:09:20.283 に答える
1
C＃よりもMFCを使用することでメリットが得られる商用ソフトウェアのタイトルの1つ、Wwise[1]が考えられます。C ++はサウンドエンジンにとって当然の選択であるため、オーサリングツールをC++で作成することも理にかなっています。これは、オーサリングツールであると同時にサウンドエンジンでもあります。彼らはC＃でオーサリングツールを構築し、C ++でサウンドエンジンを構築することもできましたが、wwiseオーサリングツールで再現可能なサウンドエンジンの問題をデバッグしている場合は、コールスタック全体をそのように見やすくなります。 。
最近、混合コールスタックを実行する方法はいくつかあると思いますが、最初にWwiseを作成したときは、それがなかったのではないでしょうか。いずれにせよ、MFCを使用することで、混合呼び出しスタックの問題に対する解決策が不要になることが保証されました。コールスタックは正常に機能します。
[1] WwiseはMFC上に構築されています：https ：//www.audiokinetic.com/fr/library/edge/？source = SDK＆id = plugin_frontend_windows.html
于 2021-04-29T17:05:59.027 に答える