久々にMFCを使ってみようと思ったけれど……
高木です。おはようございます。
最近、いろいろな形でMFCを使う仕事のことが耳に入るようになってきました。
懐かしさもあり、久々に触ってみようと思ったのですが、結論からいえば見合わせてしまいました。
今回はその経緯についてお話ししたいと思います。
まず、MFCとは一体何なのかについて、おさらいしてみたいと思います。
MFCというのは、Microsoft Foundation Classesのことで、主にVisual C++で使用するフレームワークのことです。
.NET Frameworkが普及する前は、Windowsのデスクトップアプリケーション開発の中心的な存在でした。
MFC以外には、（.NETではないレガシーの）Visual Basicもよく使われていましたし、Delphiなんかもそこそこ使われていました。
私とMFCの出会いは古く、Microsoft C/C++ 7.0に付属していたMFC 1.0から始まります。
当時はまだVisual C++ではなく、コマンドライン中心の開発環境でした。
一応、Programmers’ Workbench（だったかな？）というDOS画面の統合開発環境もありましたが、使っている人はあまりいなかったと思います。
そのころの私はWindowsプログラマーではなく（プログラマーでさえありませんでしたが）、プログラミングする場合も主にアセンブリ言語で家庭用ゲーム機が対象でした。
なので、そんなにしっかり習得したわけではありません。
その後も、主に組込み関係をやっていたこともあって、通り一遍のことはMFCでできましたが深堀はできていませんでした。
そういった状況なので、懐かしさはあるものの、そんなにMFCに愛着があるわけでもないのです。
今でも、思い出すまでに若干の時間はかかるかもしれませんが、MFCを使えといわれればできる自信はありますが、積極的にはやってこなかったのです。
ただし、私自身、よいGUIライブラリを常に探している状況でもあり、Windows限定であればMFCは常に候補には挙がってくるのです。
なお。私のブログを以前から読んでいる方であればわかるかと思いますが、GUIライブラリとして最有力なのは、今でもTcl/Tkであることに変わりありません。
そんな中、最近になってMFCの話題が耳に入るようになってきました。
MFCを使う利点について改めて検索してみました。
すぐに目に留まったのは、マイクロソフト自信が主張する「MFC ライブラリを使用する利点」でした。
この記事はVisual Studio.NET 2003に対するもので、かれこれ十数年前のものです。
現在の視点では完全に陳腐化しています。
異なるOSやプロセッサ間の移植性など、現在のMFCにはまったく当てはまらないのです。
それどころか、MFCを使う時点でWindowsにべったり依存することを覚悟することになり、移植性とはまったく無縁の世界になります。
生のWindows APIを使うのに比べてMFCを使った方が扱いやすい代表格であるMDI（Multi Document Interface）も現在では流行りません。
また、MFCの特徴的な機能であるドキュメント/ビューアーキテクチャにしても、気楽に使える軽量のGUIライブラリが欲しい私にとっては無用の長物です。
可能であれば、GUIに関する機能だけを提供してほしいのであり、それ以上のことは大きなお世話なのです。
なぜなら、GUIがプラットフォームに依存するのはある程度しかたがないとして、それ以外の部分は極力GUIからは切り離したいからです。
wxWidgetsやQtも、同じ理由で私にとっては大きなお世話なのです。
FLTKなどの軽量のライブラリはそうした問題がありません。
しかし、軽量のGUIライブラリの多くは、IMEのインライン入力ができないなど、日本語環境では致命的ともいえる欠陥があります。
なので、現在の最有力候補はTcl/Tkなのです。
MFCにしてもQtにしても、C++の最初の標準規格ができる前に誕生したフレームワークです。
昔のC++にはまともな標準ライブラリがなく、文字列クラスさえ満足になかったのです。
だから、フレームワークの機能としてそれらを提供したくなったのも至極当然のことです。
けれども、標準ライブラリが充実し、準標準的なライブラリであるBoost C++ Librariesとかも普及した現在、それらはかえって様々な弊害を生んでいます。
また、RAIIを始めとする現代的なセオリーとかけ離れた設計を持つMFCには、単に古臭いというだけでなく、使いづらさを感じずにはいられません。
そして、CStringのようなユーティリティクラスも要らない、ドキュメント/ビューアーキテクチャも邪魔ということになれば、プラットフォームSDKを直接するか、独自にラッパーライブラリを作成するほうが得策に思えてきます。
そこそこの大人数で開発を行っていた時代であれば、対応可能な人材の集め安さもフレームワーク選定の重要な要素でした。
ところが、高々数名の規模で開発せざるを得なくなった現在は、逆にそういったしがらみに束縛されることなく、純粋に技術的な視点からフレームワークやライブラリ等を選定してもよいかと思います。