- - PR -
MFCの行方
| 投稿者 | 投稿内容 | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2002-04-13 02:11
最近会議室に参加させてもらってるglassです。
今回はMFCの今後について皆さんのご意見を聞かせてもらいたいと思います。 .NETの登場で、現在のたくさんのC++プログラマーの方が「MFCはどうなるんだろう？」と思ったのではないでしょうか。 少なくとも僕はC#を知って最初に思ったことがこのMFCの行方についてです。 たしかに、Visual Studio.NETは以前のバージョンに比べMFCのサポートも拡張しています。しかし、.NET登場以後のC#に関連する記事の中でMFCを過去のものにするつもりはないと述べているものをいくつか見ました。 しかし、本当のところどうなのでしょうか？ WindowsAPIを直接叩いていた時代に比べれば、MFCというライブラリは巨大な武器でした。VisualC++ & MFC という組み合わせはWindowsアプリケーションを開発する上では絶対的な力を発揮しました。 データベースやOLEなどは数々の改良がされ、ガベージコレクションもサポートされ、ActiveXのサポートも導入し、ATLやWFCが登場してもなお愛用され続けてきたこのMFCがついに終端の航路に向けられたような思いがします。もちろんすぐにというわけではないでしょうが。 たしかに、MFCは巨大になりすぎ機能多過という面もあります。 おそらくMicrosoft自身もこれは悟っているのではないでしょうか。 生半可なプログラマーには受け入れらないでしょう。 僕も最初はその困難さゆえ、なかなか理解できませんした。今でもそうです。 しかし、MFCを使いこなせるようになることを目標にしてるプログラマーもたくさんいると思います。 みなさんはMFCの行方についてどう思われますか？ 意見をお聞きしたいです。 それでは。 | ||||||||||||||||
|
投稿日時: 2002-04-13 13:36
歴史的に見るとMFCは、MS-C 7.0で最初に登場したクラスライブラリです。
当時は、OSの主流がMS-DOSからWindowsに変わりつつあり、CUIとGUIの相違からプログラミングが複雑化して、従来の手法での開発が限界に来ていました。(これはWindowsだけでなく、Macintoshなどでも「使って極楽作って地獄」という状況でした) それまでは、主にCが使われていたわけですが、巨大化するプログラムを何とか扱うにはオブジェクト指向するしかない、ということでWindowsアプリ開発に、本格的にC++が最初に入ってきたのが、MS-C 7.0です。しかし、Windows APIを生のまま呼び出していては、ちっともプログラムがオブジェクト指向らしくなりませんから、Windows APIを包み込んで、オブジェクト指向風に扱えるようにMFCというクラスライブラリが提供されました。 こういう経緯から必然的に、MFCは、Windows APIのアーキテクチャと、C++という言語のギャップを埋める機能を与えられています。 そこから考えると、おそらく、Windows APIとC++が使われ続ける間はMFCも使われると思いますが、Windows APIとC++が使われなくなったら、自動的にMFCも引退することになると思います。Windows APIとC++は、これだけ普及しているものなので、すぐに消えて無くなることはないと思いますが、徐々に、Windows APIは.NET Frameworkに、C++はC#に置き換えられていくと思います。 | ||||||||||||||||
|
投稿日時: 2002-04-13 21:37
やはりそうですよね。 時代が変われば、開発環境も変わって行きますよね。 ただ、Microsoftにはその辺をズバっと言ってもらいたい気がします。 簡単に言える問題ではないでしょうが、せめて今後のMFCの動向くらいは説明してもらいたいです。もしかして、どっかのMSDNのページでしてたりして・・・。 今後、C++とC#はどのような関係で共存していくと思われますか？ | ||||||||||||||||
|
投稿日時: 2002-04-14 17:01
これは、@ITの記事として、ぜひMicrosoftにインタビューしてきて欲しいところですね。今のところ、Visual Basicプログラマ向けのメッセージは充実していると思いますが、Visual C++プログラマ向けのメッセージはあまり出ていないように思います。
C++とC#の他に、Managed C++の存在にも気を配らないと行けませんね。 Managed C++も.NET Framework上で実行可能なプログラムを記述できますから、C++からC#という移行の他に、C++からManaged C++という移行もあり得ます。 Windowsアプリを書く場合はC++ですが、.NET Frameworkアプリを書く場合は、Managed C++でもC#でもOKです。どちらを使ってもほとんど同等のプログラムが書けます。 現在C++を使っているプログラマが、.NET Frameworkベースで開発を迫られたとき、はたしてManaged C++とC#のどちらを選ぶかは私には予測しがたい問題です。 | ||||||||||||||||
|
投稿日時: 2002-04-14 19:07
MFCとは直接関係しないかもしれませんが、MicrosoftがC++をどう考えているのかについては、次のURLが多少参考になりそうです。
Stan Lippmanのインタビュー Stan Lippmanが書いた記事 Herb Sutterのインタビュー 帰ってきたC++コラム マイクロソフトのVisual Studio .NETのプロダクトマネージャの方も、C++のバックグラウンドをお持ちのようですし  、C++自体を軽視しているわけでは決してないと思います。ただ、じゃあMFCと言われると...どうなんでしょうか。 
| ||||||||||||||||
|
投稿日時: 2002-04-15 11:47
現在の環境を考えた場合、最低限次の視点が大切であると私は思います。
「言語 ライブラリ クラス ＩＤＥ コンポーネント」 ＭＦＣは簡単に言えば、 「Ｃ＋＋ クラスライブラリ ＩＤＥ」 の世界です。 そしてＭＦＣは「Ｗｉｎ３２ＡＰＩ」を表現・サポートする事を目的に、ＭＳが割り切って出してきたクラスライブラリだと思います。 また、ＩＤＥはあくまで言語をベースとして、クラスを意識した統合環境です。 一方、現在の開発環境の多くは 「言語 クラス・コンポーネントライブラリ ＩＤＥ」 の世界だと思います。 特に「．ＮＥＴ」の世界は、言語からも多くの重要な部分が「クラス・コンポーネントライブラリ」に移動した環境だと思います。 つまり、現在の開発環境の中心は、「クラス・コンポーネントライブラリ」です。 「クラス・コンポーネントライブラリ」を陰で支えるのは「ＩＤＥ」で、「ＩＤＥ」と「コンポーネント」の対話を支えるプロトコルもとても大切です。 「クラス・コンポーネントライブラリ」は、色んな要素を取り込みながら、ますます大きくなって行くでしょう。 開発者の立場から考えても、複数の「クラス・コンポーネントライブラリ」をベースとした開発は、何らかの標準化が行われない限り、現在のままの状況では不可能になって行くと私は思っています。 そういう意味でも「ＭＦＣ」の先は見えていると思います。 でも「ＭＦＣ」を決して否定している訳ではありません。 誤解を恐れず、ハッキリ書いてみました。 | ||||||||||||||||
|
投稿日時: 2002-04-15 13:58
やはり、皆さんの意見も大筋は一致しているようですね。
MFCが不要になるわけではない。しかし、絶対的な存在ではなくなる。 と、いった感じでしょうか。 確かに、「言語 クラス・コンポーネントライブラリ IDE」という世界に突入すれば プログラマーにかかる負担はより減りますね。 Microsoftが速度・自由度ではなく、安定性を求めていることからMFCの存在感が薄れていくのは仕方のないことではあるかもしれませんね。 愛用してきた僕としては寂しいものがありますが、MFCに固執していては先が狭くなってしまうのでしょうがないですね。 ただ、.NET Frameworkライブラリをもう少しMFCチックにしてほしかった・・・ | ||||||||||||||||
|
投稿日時: 2002-04-15 23:42
ええ、コンポーネントを利用するプラグラマーの負担は減るのかも知れません。でも、コンポーネントを作成するプログラマーの負担はむしろ増えるのではないでしょうか？ そして全体としても、負担は増えていると思います。だから、全体としての複雑さ、エントロピーを下げる努力はとても大切だと思います。C#にはそういう部分での意図も私は感じます。
Microsoftは、安定性だけでなく、速度も自由度も飽くことなく求めて行くと、私は思っています。 それでも、MFCの運命は変わらないと思います。 もう、世代が変わりつつあるという事ではないでしょうか？
どういう部分で寂しいんですか？
例えばどういう部分で？ | ||||||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。