- - PR -
MFCの行方
| 投稿者 | 投稿内容 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2002-04-16 10:10
あれこれ覚えた、クラスや関数なんぞのことです。 無駄になるわけはないですが、あんなに時間かけたのにという感じです。 でも、それなりに楽しんだので不快感はありませんが、やはりちょっとさびしいかなと。まだまだ、経験が浅いものでそう思ってしまうのでしょうか・・・
WinAPI -> MFCに変わったときには、MFCはAPIのラップといった感じでしたよね。 WinSDKプログラマーも移行しやすかったのでは？？ .NET FrameworkはMFCと共通する部分はほとんどないですよね？ というか、.NET Frameworkは独自のインフラなので当たり前ですが。 よく考えたらMFCチックにできるわけないですね。 どうせならMFCがオープンソースにならないものでしょうか？ | ||||||||
|
投稿日時: 2002-04-16 11:56
成る程ね。 私も、最初は「VC++」を使ってたので、同じく一生懸命「MFC」を覚えたんですよ。 でも、ボーランドの「Delphi」が出て…。「VCL」は「MFC」より遙かに理解すべき内容が多いですから。「IDE」だけでなく「Property Editor」等、独自のコンポーネント間の通信、設計時動作他、かなり広範囲な内容を含んでいますから。ソースはあるけど、ドキュメントが無いし。 コンパイルスピードはかなり速かったですよ。 「C++Builder」で30分位かかったのが、「Delphi」では5秒で終わったという印象がありますね。 でも、「VCL(CLX)」は確か「Java」の様に自由に配布出来ないんですね。 クラスライブラリに対する考えが違う感じがしました。 （Javaもランタイムが普及しなかったら、こんなには広がらなかった？） でも、今度のＭＳのライブラリは大丈夫だと、私は思いますよ。
「MFC」を使って今までやって来られたんですから、「.NET Framework」も大丈夫だと思いますし、却って分かり易いという部分も多いかも知れませんよ。 速度面では、同じ様な思いの人は多いと思います。私もそうですから。 みんなで「.NET Framework」上でも速度向上をもっともっと求めて行きましょうよ！ 「MFC」のオープンソース化ですか。 プラットフォーム依存の部分は、「MFC」使ってるのかな？ これは、どうなんでしょう？ | ||||||||
|
投稿日時: 2002-04-16 14:29
Visual C++の動向といえば、ANSI（だっけ？）標準準拠の標準C++ライブラリは結局入りませんでしたね >VC7.0
ATLや、MFCその他との絡みでいじれない部分もあるのかとも思いますが、Visual C++については標準準拠という面では終わったなという印象（始まりもしなかったか？）ですね。 オープンソース系、特に UNIX等で開発しているグループでもこれまでは何とか Visual C++をサポートしてくれていますが、Xearcs/Xalan 等の apache.org系のソースを使っているとVC++のSTLにはバグ＆標準相違があるからライブラリを入れ替えろとはっきりかかれてますしGCCの方が手間かからなくて良いなぁ…とか。 今の段階ではVC7.0にSTLportを乗っけて何とかしのいでいるのですが…C++についてはGCCへの移行を考えています。（でもデバッガだけはVC++に頼ってしまう） まぁ、そうなるとMFCなど無いのでC++でWin32 SDKの世界なんですが、別に困るわけじゃぁ無いし、コアロジックをCOMオブジェクトとして作ってしまえばコンテナには事欠かないし、コアロジックがCOMオブジェクトといってもFacadeするだけなのでFacadeのデバッグ以外ではWindows上で作業する必要も無いし… WebServiceもSOAP受けるライブラリがきちんとしてればISAPI/Apache ModuleでC++で書く方がパフォーマンス出るし、ISAPIとApache Moduleの違いなんて微々たる物なのでラッパかましてどっち版も作れます…という具合で VS.NetがリリースされてWindows系を触る意思がめっきり減った今日この頃です。 私もMFCの資産はあるのですが、MFCには固執しません。 ご苦労様でしたと素直に封印するつもりです。 | ||||||||
|
投稿日時: 2002-04-16 19:05
MFCが提供する機能はいくつかに分類できます。
1) プリミティブな機能（CString・CArrayなど） 2) Windows APIのラッパ（CWnd・CDCなど） 3) アプリケーションの構造に関するもの（CDocument・CViewなど） 1)・2)については.NET Frameworkも提供してくれます。しかし、3)にはどうでしょう？ MFCが提供するドキュメント=ビュー構造は、標準的なWindowsアプリケーションの作成を強力に補助します。アプリケーションの構造を明快にすることは重要な利点です。 また、 ・現在開いているファイルの名前をウィンドウキャプションに表示する。 ・最近使ったファイルの一覧をファイルメニューに追加する。 ・ドキュメントの変更を全てのビューに反映する。 などの細かな処理を行っていることも忘れてはいけません。 Windows Formsアプリケーションの開発では、MFCが行っていた多くの処理を新たに書くことが必要になります。これはとてもうんざりする作業です。 .NET Framework上で動作するMFCというものが必要になるのではないでしょうか。 | ||||||||
|
投稿日時: 2002-04-17 11:59
ドキュメント=ビュー構造に上手く収まらない事例をいくつも見ているので、標準でドキュメント構造を強制するのも善し悪しだと思います。 そういう構造は、必要に応じて追加して使うのでは駄目なんでしょうか? | ||||||||
|
投稿日時: 2002-04-17 13:18
確かに「ドキュメント=ビュー構造」を強制する事があってはいけないと私も思います。 でも、データの方がより本質的であり、その見え方に対するユーザーの要求は変化し易い、という視点に立てば、「ドキュメント=ビュー構造」一番に採用したいという開発者がいるのも自然な事だと思いますし、それをフレームワークでも対応出来る事は大切だと私は思います。 特に、ＭＳの場合、「ＶＳ」で基本的に対応した訳ですから。 「Delphi」は、確か現在でも「ドキュメント=ビュー構造」をフレームワークではサポートしていないと思います。 でも、途中から「データーモジュール」が導入されました。 これは、フォームと同じ様な、データに対するコンテナで、ＤＢ（ＳＱＬ他）に対するツール機能を含んだものです。 開発環境がコンポーネントベースである現在の状況を考えると、データサポートが「データーモジュール」の様な形で供給されるのは、殆ど必然ではないでしょうか？ ＭＳにはＸＭＬが処理出来、「ドキュメント=ビュー構造」にも対応した「データーモジュール」を要望したいですよね。 ＭＳは現在これに対する対応を、懸命に行っていると考え、暫く待ってみては？ | ||||||||
|
投稿日時: 2002-04-17 13:36
MFCはドキュメント=ビュー構造を強制しているわけではありません。ダイアログスタイルやエクスプローラスタイルなどいくつかのスタイルをサポートしています。正しいスタイルを選択すればたいていのアプリケーションではうまくでしょう。どうしても駄目なら、フレームウィンドウから自分でカスタマイズすれば良いだけのことです。
使う使わないはプログラマの自由です。機能が提供されることに意義があるのだと思います。 大きな恩恵を受けるプログラマはきっと多いと思います。 | ||||||||
|
投稿日時: 2002-04-19 15:34
はじめまして。
標準C++ライブラリについてはVC6からかなり進歩したように見えるのですが。 見たところ、Dinkumware (http://www.dinkumware.com/) の C++ Library V3.10 相当のものが入っています。VC7.0のSTLの各ヘッダファイルには、 Copyright (c) 1992-2001 by P.J. Plauger. V3.10:0009 とあります。VC6.0では、 Copyright (c) 1995 by P.J. Plauger. でした。 | ||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。