MFCフレームワークは現役?覚える価値あり?

今更時間をかけてMFCを覚える価値あるんでしょうか?と、若手から聞こえてきそうな昨今(2008/12執筆時点)。
題記について私の考えを書いておきます。

結論から言うと、.Net言語の台頭により、Winアプリを作る上でベストの開発環境では無くなったが、製品開発等高速処理性能やネイティブ機能が必要な場合、他のC/C++資産との結合等が必要な場合においては、当分はベストの開発環境である。

もちろんフレームワークも適材適所で、MFCである必要が無い分野もあります。
私の経験から言いますと、VC++6の頃にMFCかじって、仕事で他の大規模Appとバイナリデータ交換し機能を付加するような小規模なWindows App製品を開発していました。
それからしばらくWindows Appを作る機会が無く、.Netも台頭してきてもう触ることも無いかと思ってたのですけど、最近またMFC使ってWindows App作ることになってしまいました。

C#なども浸透しつつあるんですが、周辺のソースがC/C++だったり、グラフィックスやメモリ処理や・・ちょっと複雑で、時間制約のある処理を実装しようとするとC#ではインピーダンスミスマッチが起こるし、重くて実用に耐え難くなるし、ガベージコレクションは不安定要素になるし、より複雑な機能を追加する必要があるかもしれないという意味では将来性もなくなってしまう可能性もある。
このような分野、状況においてはMFCは当分存続することになるでしょう。

MFCのフレームワークは難解だとか設計が古いとかいろいろ文句もあるでしょうけども、一からC++でウィンドウを使ったAppを組む方法について考えていくと結局は、多少形は違えど、こういった形になるわけです。また、性能やオリジナルな処理が要求されれば下層まで踏み込んでいくのはWindows Appに限らずともよくあることです。MFCを覚えるというよりは、設計の本質を覚えるということであれば納得して取り組めるでしょう。
C/C++についても、組み込みでプロセッサの新型がでればアセンブラ→C言語→C++という順に開発環境が整えられる限り、最重要であることに変わりありません。その周辺のUIはC/C++ベースのほうが親和性が高いわけです。

また、C++でMFCとは別の理想の環境が無いわけではありませんが、なかなか成熟してくれません。(Qtなど。これは別途追いかけて行きたいです。)

とまあ・・ごちゃごちゃ書いてますが、いろいろあって、再入門することにしました。
最終更新:2009年10月27日 19:55
ツールボックス

下から選んでください:

新しいページを作成する
ヘルプ / FAQ もご覧ください。