MFC の魅力的な機能は何ですか? なぜそれを新しいプロジェクトに選んだのですか？
4797 次
14 に答える
18
MFC は 10 年前は良い選択肢でした。これはまだ Win32 API の優れたラッパーですが、残念ながら廃止されています。
Qtは、プラットフォームに依存しないという 1 つの大きな利点を持つ優れたオプションです。MFC を使用すると、Windows に運命づけられます。
于 2008-09-23T14:23:12.950 に答える
11
私は今でもあらゆる種類のアプリケーションに MFC を使用しています。MFC は初期の実装から悪い評価を受けましたが、今では優れています。WTLよりもかなり便利だと思います。さらに、Visual Studio の GUI ツールは既にセットアップされており、MFC を使用した GUI の迅速な開発、変数へのコントロールのマッピング、DDX などを簡単に行うことができます。
広く配布する予定のデスクトップ アプリケーションについては、通常は MFC のネイティブ Windows アプリケーションを使用します。これは、使用する .NET のバージョンを顧客に依存できる段階にまだ達していないためです。アプリを実行しようとした結果、.NET のインストールに問題が発生した場合、カスタマー サービスの頭痛の種になることは言うまでもありません。
于 2008-10-12T14:14:50.473 に答える
9
MFC の利点は、win32 をそのままコーディングするよりも優れており、.Net のように 23 ～ 50Mb のランタイムを必要としないネイティブ .exe を配布できることです。
これらのことについて懸念がある場合は、C++ Builder、WxWidgets などのより良い代替手段があります。ただし、Microsoft 以外のツールを考慮しない場所もあります。
于 2008-09-23T14:07:15.500 に答える
9
なぜデスクトップ アプリに C# ではなく C++ を選択するのかという質問を言い換えることができます。C++ は依然として、一部のアプリケーションにとって重要な速度の利点を提供します (私は、電子取引用のソフトウェアを作成する会社で働いています。速度は非常に重要です)。
C++ のみで Windows 向けのデスクトップ アプリを開発する場合は、MFC が最も成熟した選択肢であり、インターネット上の MFC に基づく無料のコードがたくさんあり、多くの知識があります。
于 2008-09-23T14:08:54.483 に答える
8
win32 api 自体とは別に、MFC は、15 年以上経った 2011 年にまだ健在である唯一の主流の Windows プログラミング テクノロジです。2001 年にさかのぼると、誰もが「MFC は終わった。今はすべて Winform だ」と言っていました。2005 年には、誰もが「MFC は死んだ。今はすべて XAML だ」と言っていました。現在は 2011 年で、Winforms と XAML は廃止され (OK XAML は実際には廃止されていないかもしれませんが、最盛期を過ぎています)、MFC は最新の開発 (リボン、Aero 拡張機能、Win7 API など) で更新され続けています。
もちろん、これで将来が保証されるわけではありませんが、この 15 年以上にわたって多くの MFC コードが作成されており、今後 10 年または数十年にわたって使用され続けるでしょう。それは最も美しい技術ではないかもしれませんが、よく理解されており (その良い点と悪い点)、他の誇大宣伝技術のように動くターゲットではありません。とにかく、代替案よりも）。
(C++ についても同様です)
于 2011-09-15T12:11:00.657 に答える
7
ここに可能性があります - 大量のメモリを必要とするアプリケーション、たとえばグラフィックス プログラム、ゲーム、または高性能ビジネス アプリケーションを想像してみてください。.NET アプリケーションがメモリを大量に消費することは周知の事実です。このような場合、アプリケーションのコアに無駄のない MFC アプリが必要になることがあります。COM 呼び出し可能ラッパーを介して、または C++/CLI を介して直接、.NET コンポーネント、コントロールなどをいつでもロードして使用できます。
とはいえ、MFCは面倒です。代わりに WTL を検討してください。MFC について前述したのと同じ方法で、必要に応じて .NET を呼び出すこともできます。WTL は MFC よりもはるかに優れています :-)
于 2008-09-23T14:18:20.950 に答える
5
どうやら、POS デバイスなどの Windows ベースのハンドヘルド デバイスのアプリケーションには依然として適しているようです。これらでは、リソースが限られているため、メモリ管理などがより重要になります。
于 2008-09-23T14:08:39.693 に答える
4
新しいリボン コントロールがあると聞きました。この種の複雑さに興味がある場合。新しく生成されたアプリのスクリーンショットを次に示します。
(ソース: msdn.com )
本当に、それは単なるウィジェットの更新です。では、さらにウィジェットが必要ですか?
于 2008-09-23T14:06:45.113 に答える
3
既存の Windows API は完全に C ベースです。C++ を使用したい場合 (おそらくそうすべきです)、ネイティブのままでいたい場合 (つまり、.NET を使用しない場合) は、MFC を選択するのが理にかなっています。
MFC は、C API の上にあるオブジェクト指向クラスのセットです。さらに、日常の作業を簡単にする「ヘルパー」クラスが多数追加されています。
于 2008-09-23T14:09:39.723 に答える
3
私はそうは思わない.. MFCは負けるだろう
- 抽象化のレベル
- 開発時間
- トラブルシューティング時間
- 新しい開発者の学習曲線
- 将来の保証 (ただし、3 ～ 4 年ごとに何か新しいものが登場するため、今は疑問です)
- 自分の MFC を知っている良い人を見つける
- 使いやすいコントロール
MFC がこっそり通り過ぎる唯一の場所は、画面上に 10 ミリ秒または 1 秒ごとに再描画する必要があるものなど、非常にパフォーマンスを集中的に使用するアプリケーションがある場合です。「マネージド」アプリは、まだそのハードルを乗り越えることができていません。
MFC は進化の重要なステップでしたが、現在ではより優れたオプションが利用可能です。
于 2008-09-23T14:31:43.103 に答える
2
速度とフットプリントが.NETを超える正当な理由だと思います。
優れたMFCプログラマーを見つけるのは難しいことは確かですが、現代語は怠惰なプログラミング手法を促進し、ほとんどのプログラミングコースは、教えるのが簡単であるため、それらに引き寄せられるためです。
于 2009-05-12T09:39:39.757 に答える
2
Einar が既に述べたように、C++ で Windows CE およびモバイル アプリを開発している場合は、MFC が適しています。この選択を行うと、デスクトップ デバイスとハンドヘルド デバイスで同じコードを使用できるため、MFC はデスクトップでも妥当な選択になります。このシナリオでは、MFC は優れたパフォーマンスを維持し、組み合わせを簡単に実装できます。個人的には、MFC をこれらの環境で Stingray ライブラリと組み合わせて使用しています。これにより、非常に優れたインターフェイスと優れたパフォーマンスが得られ、迅速かつ簡単に実装できます。
于 2008-10-12T14:03:02.837 に答える
2
デザインと技術的なメリットだけで？断定的で申し訳ありませんが、ありません。これは貧弱な設計であり、Win32 API プログラミングにフォールバックしなければならない非常にリークの多い抽象化であり、C++ をひどく悪用し、昨日のテクノロジをしっかりとターゲットにしています。 MFC アプリ。C# 開発者を獲得でき、重大なハードウェア制限がない場合は、WinForms を使用してください。
一方、採用能力、トレーニング プログラム、サード パーティ製コンポーネントなどの外的要因は、少なくとも一部の種類のアプリケーションでは寿命を延ばすことができます。できれば社内で。
于 2008-09-23T14:09:50.567 に答える
1
私は何年もクロスプラットフォームのコードを書いてきたので、何かを書く必要があるときは常に、それと posix 呼び出しを除くほとんどすべてのシステム呼び出しの間に非常に薄い抽象化レイヤーがあります。そうすれば、MFC でコーディングできますが、後で必要に応じて別の API に簡単に変換できます。私がすべてに使用する C++ ライブラリの基本セットは、小さな System クラスでこれを行います。現在、Windows 用の MFC を使用しており、Linux 用の XWindows とネイティブ Mac バージョンも使用しています。後でハンドヘルドに移植するときは、まったく問題はありません。
のぞき見したい場合は、LGPL されており、次の場所にあります。
于 2008-09-23T14:23:44.323 に答える