1 ：
名無しさん＠お腹いっぱい。：
ＭＦＣを初めて使いはじめましたのですが、困るぐらいノウハウの固まり
なんですね。クラスライブラリというのは得てしてそういうものかもしれ
ませんが....
簡単なプログラムを速く作るのにはよさそうですが、手塩にかけたプログ
ラムを作ろうと思ったら、MFCを使うべきでないという気分になりかけて
います。ＭＦＣを使うべきかどうかのガイドラインってみなさんどうされて
います？
同じようなスレが定期的に立つな。
3 ：
名無しさん＠お腹いっぱい。：2000/12/26(火) 03:09
めんどくさそうなんでできません。VBから入ったから余計に。
4 ：
ゲイツ：2000/12/26(火) 03:24
これからはC#の時代だよ！
5 ：
名無しさん＠お腹いっぱい。：2000/12/26(火) 03:49
＞２
そーなのか。で、前回の結論はどんな感じだったの？
6 ：
名無しさん＠お腹いっぱい。：2000/12/26(火) 04:08
>>1 今年の夏ごろからMFC使い始めました。
最初は、ダイアログベースで遊んでいたのですが、
APIだけで作るのよりはずっと楽だと思いました。
今は、DOC/VIEWを勉強中なのですが、
ダイアログベースで作った物をDOC/VIEWで作り直そうとすると、
DOCの部分に何を書いていいのかわかりません。
7 ：
名無しさん＠お腹いっぱい。：2000/12/26(火) 04:19
ファイル/データの処理をDOCに書いて、表示処理をViewに書くのが一般的のようだ。
俺はほとんどViewに書く大ばか者ですが・・・
8 ：
名無しさん＠お腹いっぱい。：2000/12/26(火) 04:27
DOC の Serialize ってのが全然分からん。
良く分からんから自分でメソッド作って CreateFile で普通にファイル開いて入出力してる。
9 ：
名無しさん＠お腹いっぱい。：2000/12/26(火) 05:10
いつどこが呼び出されてるのかわかりずらいです。
それさえなんとかなれば便利な道具と言えると思います。
10 ：
名無しさん＠お腹いっぱい。：2000/12/26(火) 05:13
Serialize 最悪。
ファイルの読み書き時に呼び出されるらしいけど、
開いたファイルの中身が空だったりすると呼び出されなかったり。
そういうものなんだろうけど、じゃ空の時はどこで処理すればいいんだ？
ってことになる…
>>1 GUIなんかのWin32APIべったりなのはMFC
純粋なロジックはそれ以外(STLなりなんなり
つーかんじかしら。
Archive の、心意気は買うけど資料あんのか？あれ。
12 ：
名無しさん＠お腹いっぱい。：2000/12/26(火) 12:03
MFCのCOM実装はダメダメなのでもうおしまい。
ATLがSTLベースになってDoc/Viewアーキテクチャが実装されて
MFCなみのコントロールラッパがあれば理想。
同じようなスレが立つたびに言っているかもしれん。
さいきんMSからWTLという伏兵もでてきている。
ソースは配布されているが
まともなドキュメントが無いのでよくわからないが
ATLにMFC的な要素を加えたものらしい。
13 ：
名無しさん＠お腹いっぱい。：2000/12/26(火) 12:33
>>1 今の時代じゃ、MFCよりほかのものを使ったほうが適切な場合がほとんど。
入門用途じゃ絶対におすすめしないし、それなりのもの作れるようになるまでも
手間かかりすぎでダメダメ。
MFCしかない環境なら、心中するつもりで突っ込むべし。
それがいやなら、別のものを探しましょう。
14 ：
名無しさん＠お腹いっぱい。：2000/12/26(火) 12:37
>>12 WTLってDonutの作者のページで解説してるやつけ？
15 ：
12：2000/12/26(火) 12:55
>WTLってDonutの作者のページで解説してるやつけ？
Donut? しらないです。
Platform SDKをダウンロードしたらついてきた。
(Platform SDK 全部で650MB近く。T_T;)
ちなみにWTL=Windows Template Libraryだそうです。
WTL用のAppWizardもついている。
16 ：
12：2000/12/26(火) 13:17
17 ：
名無しさん＠お腹いっぱい。：2000/12/26(火) 14:05
WTL、面白そうですねぇ。
なによりトレースしやすそうで心強い。
折角だから期待age
18 ：
名無しさん＠お腹いっぱい。：2000/12/26(火) 14:55
WTLは一応英語で読んでる。
疲れる。
19 ：
名無しさん＠お腹いっぱい。：2000/12/26(火) 15:20
WTLとC#ってのはまったくちがうのけ？
2000年にリリースされてきたってことは
VJ++WFC -＞ VC#
VC++MFC -＞ VC++WTL
VB －＞ VBNET
MSはこの3本立てを用意しているって事なのかな？
VB.NETはC#の下請け
21 ：
名無しさん＠お腹いっぱい。：2000/12/26(火) 15:36
>>19 WTLとC#は同じ会社のものです。
その意味では同じかもな。
あ～、話しがどんどんMFCから遠ざかっていく～(笑)
WTL落とそうと思ったのにMSのftpにアクセスできない・・・鬱
このスレのタイトルへの回答としては「否」ということで、
ゆっくりまったりWTLの話しでもしようっか
25 ：
>23：2000/12/27(水) 00:20
あれほんとうだ。
> 530 User IEUser@ cannot log in, home directory inaccessible.
なんだ？
26 ：
デフォルトの名無しさん：2000/12/27(水) 03:47
ブラウザからじゃなくてftp clientで行ってみな。
28 ：
デフォルトの名無しさん：2000/12/28(木) 00:32
せっかくなんでWTLのスレ作っていいですか?
29 ：
デフォルトの名無しさん：2000/12/28(木) 11:44
30 ：
デフォルトの名無しさん：2000/12/28(木) 11:45
31 ：
デフォルトの名無しさん：2000/12/28(木) 12:19
WTLはレスがそう多くは帰ってこないよ。
多分。
英語の文書ばっかだし。
32 ：
+-*%/：2000/12/28(木) 13:03
逆に、他のメディアにいくらでも登場する情報を
あえて２ちゃんで提供する意味ある？
他で調べて不明で、誰もわかる人いないから、
２ちゃんへ来るってのが理想だと思うけど。
33 ：
28：2000/12/28(木) 13:27
>>30 ATLといっしょにしたらレス増えるでしょうか?
とりあえず、ここで様子みて
増えるようなら別スレにすれば？
35 ：
デフォルトの名無しさん：2000/12/29(金) 01:02
ATLでお勧めのページを教えてください
36 ：
デフォルトの名無しさん：2000/12/29(金) 02:02
MFCって具体的にどこが気に入らない？
参考程度に教えてよ。
37 ：
名無しさん＠お腹いっぱい。：2000/12/29(金) 02:14
＞36
ＭＳ社員発見！
ＭＦＣはＳＤＫで組んだこと無い奴には便利かもしれんがＳＤＫで組んでた奴には色々制限が多いっていうかＭＦＣ流のコーディングスタイルに合わせないといけないので面倒臭い。
クラスウィザードからポチッと関数加えたら、すでにその関数の
中にコードが書かれている辺りに、中途半端なクラスライブラリに
悪意としかとれない使い勝手のツールをくっつけてプログラマを
苦しめているとしか思えません、ウヘ。
39 ：
名無しさんi486：2000/12/29(金) 03:05
>>38 分かって使えばたいした事なかろう。
どこが苦しいんだかよく分からん。
40 ：
minima＠順風満帆：2000/12/29(金) 03:39
MFC，分かるまでが異様に大変ですよね。
COMMAND や UPDATE_COMMAND_UI ていうメッセージが謎だったり，
「イベントハンドラ」てのがいつどこで呼び出されてるのかよく分からなかったり，
CCmdUI* て何じゃらほい，だったり，BM_CLICKED だったり。
Windows 以前にオブジェクト指向のオの字も知らないままプログラミングをやってると，
どうしてもトップダウンなコードしか認識できないっていうか，うー，そんな感じっす。
# ええっと，今 MFC の解説書を読んだんですが，スラっと理解できました・・・
# ３～４ヶ月前はちんぷんかんぷんだったのにな。笑い
41 ：
名無しさん＠お腹いっぱい。：2000/12/29(金) 04:21
>>40 その解説書の名前おしえて！
おれもよんでみたい
42 ：
名無しさん＠お腹いっぱい。 ：2000/12/29(金) 04:23
>40
おれにもおせーて！
43 ：
デフォルトの名無しさん：2000/12/29(金) 10:45
>>41-42
つーかさぁ、ソースあるんだから見ろよ。
いい悪いは別にしても、いろいろ興味深いテクニック満載だから。
44 ：
minima：2000/12/30(土) 04:41
>>41-42
わー，すんません。誤解させてしまったみたいっす。
参考書はVC++5.0についてきた「VisualC++5.0プログラミング入門」です。ASCIIのね。
Windowsのメッセージのやりとりを理解しないままこの本を読むとちんぷんかんぷんでした。
しょうがないので WinMain() から書いて，とりあえずゲームみたいなのを作っているうちに
だんだんと「WM_*****」のなんたるかが分かってきたんですよー。
んで今その本を読むと，あぁ，なんだ，こんなことだったのか～てな感じで。
Townsの頃が懐かしいです。何も考えずに MOS_mouse(&b,&x,&y); とかやってれば
自動的に b,x,y にボタンの状態とかマウスの座標とかをセットしてくれてましたもんね(´ー`)
45 ：
デフォルトの名無しさん：2000/12/30(土) 06:07
やっぱ初心者やDOSのプログラミングに慣れてる人にとってMFCがわかりにくい一番の理由はイベントドリブンの概念なんですかね・・・?
46 ：
名無し戦隊ナノレンジャー！：2000/12/30(土) 06:35
イベントドリブンが分かっていてもＭＦＣはイヤ。
ＳＤＫとはイベントの呼ばれ方が違う。
っていうか何かムカツク！
47 ：
46：2000/12/30(土) 06:37
やばい「なんでもあり板」から来たのがバレた！？
48 ：
デフォルトの名無しさん：2000/12/30(土) 10:56
初心者でもイベントドリブンが理解できないってことはないでしょ。
みんなVB愛好家だし(藁)
MFCってAPIのラッピングに過ぎない部分と、C++ライブラリとしての部分があるんで
結局APIがわからないとMFCもわからない。
C++がわからないとMFCもわからない。
ってことでは？
MFCはクソだがMFCすらわからないヤツはもっとクソ
49 ：
１：2000/12/30(土) 11:33
MFCなんかヤメトケというお達しが出たにもかかわらず、Win32APIで
組んでいると生産性悪いので、結局MFCにもどっちゃいました。なんか
最近慣れてきちゃった。こまりましたな。
はー、
どこへ行っても生産性生産性・・・。
51 ：
デフォルトの名無しさん：2001/01/04(木) 06:01
52 ：
MFC信者：2001/01/04(木) 06:21
なんかMFCはクソだとか言ってる人多いですが・・・
ただ単に理解できなかっただけなんでしょ（笑ひ）
53 ：
デフォルトの名無しさん：2001/01/04(木) 08:38
いや、本当にクソだよ。
ただ現時点では他に選択肢がないからしょうがない。
BorlandのＯＷＬの方が全然使いやすかったね。
54 ：
名無しさん＠お腹いっぱい。：2001/01/04(木) 10:32
すぐにC#とWTLが一般的な選択肢になるよ。
55 ：
＞５４：2001/01/04(木) 11:00
良いものが認められ使われるとは限らないのはOWLを見てもあきらか。
政治的なメリットが無いとね
56 ：
デフォルトの名無しさん：2001/01/04(木) 11:06
逆に一般的に認められるにしたがって酷くなっていくものもおおいけどな。
57 ：
MFC信者：2001/01/04(木) 13:29
クソとか言ってる人は具体的に批判してみたら（笑ひ）
＞ただ現時点では他に選択肢がないからしょうがない
はひ？
自分で作れよ（笑ひ）
58 ：
ＭＦＣ批判：2001/01/04(木) 15:23
59 ：
MFC信者：2001/01/04(木) 18:42
>>58 あれ以上OOしたら逆に使いづらくなる。
どこをOOにすればいいの？
おいおい、ＭＦＣの何処がＯＯＰなんだよ(怒
いい加減なこと言うな！！！
MFCは、COMとかシェルとかUIのMSアホ機能へアクセスするブリッジとしてしか
使ってない。よって、別にOOであろうがなかろうが一向にかまわないんだが。(藁
逆にDLLとかで呼出す形式の方が助かる。
デカイんだよ！
62 ：
デフォルトの名無しさん：2001/01/04(木) 19:08
>>61 同意。ＭＦＣをスタティックリンクするともう・・・(涙
63 ：
MFC信者：2001/01/04(木) 19:40
>>60 SDKと比べたら遥かにOOPですが。
>>61,62
デカイと何か困りますか？いまどき。
64 ：
MFC信者：2001/01/04(木) 19:47
訂正
SDKと比べてもしょうがない。
いいたかったのはあれ以上OOPにしたって対した利点は
ないってこと。
65 ：
名無しさん＠お腹いっぱい。：2001/01/04(木) 19:53
おれも早くMFCのタコさに気づくぐらいのレベルになりたいな。
（そうです。UNIX/Cのドキュソぷろぐらまです 藁）
ところで今のWindowsにCではアクセスできないインターフェイスは
あるのでしょうか？
すみません。どなたか教えて下さい。
COMのインターフェイスはCでも大丈夫と聞いたのですが・・・
66 ：
MFC信者：2001/01/04(木) 20:14
>>65 >おれも早くMFCのタコさに気づくぐらいのレベルになりたいな。
安心してください。ほとんではMFCを批判すればなんかかっこいいじゃないかって
思ってる厨房たちです。
それからCでアクセスできないインタフェースは無いです。
67 ：
名無しさん＠お腹いっぱい。：2001/01/04(木) 20:29
>66 ありがとうございます。
今からMFCをなんとか使えるぐらいになりたいと思います。
さすがにCじゃ辛そうなので(藁
＃MFCでWindowsアプリ作るのもおもしろそうじゃん！
＃Delphiも面白かったし。。。あーこんな世界があったんだ。。。（涙
68 ：
禁断の名無しさん：2001/01/04(木) 21:01
69 ：
名無しさん＠お腹いっぱい。：2001/01/04(木) 21:23
>68 -先のドキュソだけど-
>もしかしてＭＦＣしか知らない人？
MFCしか知らなくてもいいんじゃん？
事実上のスタンダードなんだから。
他にスタンダードって言えるような
C++のライブラリなんてある？
性能云々いうんだったら、Cで作れば
いいじゃない（藁
どっちにしてもWindowsアプリを作る動機に
長いものに巻かれろ、的な考えが基に
あるだろうから、善し悪しを真剣に
論じること自体がなんだかねぇ。
＃私もMFC、信じてます（藁
70 ：
デフォルトの名無しさん：2001/01/04(木) 21:35
VC++6から、static linkでも結構小さくなったような気がするんだけど。
ただMFCってdll版とstatic版でびみょーーーに動作違ったりするのよね。
分割ウィンドウ上のマウスカーソルとか。
＞それからCでアクセスできないインタフェースは無いです。
めんどい
72 ：
MFC信者：2001/01/04(木) 23:35
>もしかしてＭＦＣしか知らない人？
はひ？だとしたら何ですか？
本業はVBですが（笑ひ）
具体的な批判まだぁ？
MFCを否定するつもりなぞありませんが
なんどやってもVCLのほうが楽だなぁ‥と思います。
「スタンダードだから」とか「参考資料が多いから」とか以外で
MFCが優れているというところっていったいどこなんでしょう？
74 ：
デフォルトの名無しさん：2001/01/04(木) 23:53
なんだかんだ言って、MS純正ってのは色んな意味で安心。>73
とか言ってみるテスト
安心を買うために苦労はしたくないなぁ
なんて言ってみたりするテスト
76 ：
62：2001/01/04(木) 23:57
>63
>デカイと何か困りますか？いまどき。
1MB超えるとFDに入らない。(藁
これが意外と困るんだよ。
客先のマシンがFDとCD-ROMしか無い場合、FDに圧縮
して持っていく羽目になる。しかも、圧縮して1MBに
納まらないと圧縮ファイルを分割して複数FDで
持っていくとかCDに焼くとかまぁ色々と面倒なんだよ。
ネットワークやMOが使えるならそっちを使うけど
未だに無いところも結構あるからね。
77 ：
MFC信者：2001/01/05(金) 00:07
>>73 VCL使ったこと無いのでMFCと比べてどうかということは分かり
ません。（笑ひ）
>>76 納得（笑ひ）
>76
一つのファイルが1MB超えるってなんか作り方間違ってないか？
ま、そういう時もあるか。
CDRWがお勧めだね。
おい、MFC信者よ。具体的な批判をしてやるぞ。
おまえチンポついてるか？チンポついてるならMFCなんか使わず
アセンブラで全部かけ！バカモンが！
アセンブラでかけないやつはチンポがちいさいか、ホウケイだ。わかったか！
あ～うぜえ>79
sageてるからまだいいけど。
>79
ついてません。
82 ：
名無しさん＠お腹いっぱい。：2001/01/05(金) 00:52
>>69 長いものに巻かれろ的な考え方ならますますMFC
は、やめたほうがいいんじゃないか？
間違いなく衰退していく技術だから。
あーもういいよ。
いまどきMFC使う奴はドキュｿ。
って結論でおしまい。
84 ：
MFC信者：2001/01/05(金) 01:06
まだぁ？
86 ：
MFC信者：2001/01/05(金) 01:10
結局逃げられたぁ
おいMFC信者！おれの批判はわかったのか？！
わかったのならイッテヨシ！
だれに？>86
もう寝るぞｸﾞﾗｧ（`Д´）
あしたまた来てやるから、ちゃんと考えとけな。ъ( ﾟｰ^)
ｵﾔｼﾐ
プロトタイピングはそれなりに早く終えることが出来るが、
それ以外の事についてはお荷物でしかない。
まともな奴ならMFCをいつでも切り離せる様に作るだろう。
91 ：
デフォルトの名無しさん：2001/01/05(金) 01:26
ドキュメント／ビューモデルなんかよくできてると思ったよ。
最初に出てきたときにはね。
長いtiﾑpoに巻かれるのもどうかと思うぞ。
93 ：
12：2001/01/05(金) 07:06
だめだめなCOM実装をなんとかしろよ
包含クラスとしてインタフェースを実装しなければならないから
ルートクラスにアクセスするのにへんなポインタ変数使わなきゃならない
IDispatchの実装のために変なテーブル作らなければならないのも解決しろよ
独自テーブルなんてやめてタイプライブラリ経由でデュアルインタフェースとして
実装できるようにしろ。とうぜんClassWizardも対応させること。
今日中に解決策をあげること＞MFC信者
>>93 MFC信者にそんなこと言ったって判らんと思うが。
変なテーブルが必要なのは、Cでも動かせる必要があるからなんじゃ？
そういう意味でQueryInterfaceの辺りは別に悪いとは思わないけど。
COMの問題は別の所にあるのでは。
95 ：
デフォルトの名無しさん：2001/01/05(金) 08:47
>>91 >ドキュメント／ビューモデルなんかよくできてると思ったよ。
Doc/Viewモデルは別にＭＦＣが発明したわけじゃないでしょ。
ＯＷＬにもあったし、ＯＷＬに比べるとＭＦＣのDoc/Viewは
間に合わせで作った感じがする。
大体ＭＦＣのクラスって何で多重継承利用してないの？
ちゃんとした理由知ってる人教えてん。
継承元が全面仕様変更になっても動くようにだろ（藁ひ）
97 ：
デフォルトの名無しさん：2001/01/05(金) 10:30
>>95 多重継承を利用したクラスライブラリが優秀とは限らないぞ。
だからＭＦＣがすぐれていると言う気は全くないが。
私はクラスライブラリにおいて多重継承を使うかどうかは、設計理念としての
選択肢のひとつだと考える。
98 ：
デフォルトの名無しさん：2001/01/05(金) 10:39
シリアライズ機能はイラネー
99 ：
デフォルトの名無しさん：2001/01/05(金) 11:24
>>96 ルートオブジェクトCObjectがあるんで多重継承しちゃうと
ルートオブジェクトが２つになっちゃうからでしょ。
101 ：
MFC信者：2001/01/05(金) 14:29
>包含クラスとしてインタフェースを実装しなければならないから
>ルートクラスにアクセスするのにへんなポインタ変数使わなきゃならない
変なポインタってpThis のこと？
マクロ一行書くくらいでわめくなよ（笑ひんぐ）
>IDispatchの実装のために変なテーブル作らなければならないのも解決しろよ
>独自テーブルなんてやめてタイプライブラリ経由でデュアルインタフェースとして
>実装できるようにしろ。とうぜんClassWizardも対応させること。
変なテーブルってDISPATCH_MAPのこと？ClassWizardが作ってくれるんだから
いいじゃない。
ヂュアルインタフェースじゃないと困ることありますか？
おそい？ほんと？試した？どのくらい遅くなった？（笑ひ）
>変なテーブルが必要なのは、Cでも動かせる必要があるからなんじゃ？
激しくはひ？チミ、恥かきたくなかったら、あんまりかきこまないほう
がいいかもね。恥かくのが好きなの？ｶｯｺｲｲ
>シリアライズ機能はイラネー
シリアライズが有効な例・・・CMapStringToStringをシリアライズする場合
書きこみ処理--->
CMapStringToString stringmap;
stringmap["１月"] = "January";
stringmap["２月"] = "February";
CFile file;
file.Open("c:\\ddd.data", CFile::modeCreate | CFile::modeWrite);
CArchive ar(&file,CArchive::store);
stringmap.Serialize(ar);
<---書きこみ処理
読みこみ処理--->
CMapStringToString stringmap;
CFile file;
file.Open("c:\\ddd.data", CFile::modeRead);
CArchive ar(&file, CArchive::load);
stringmap.Serialize(ar);
<---読みこみ処理
自分でやるより遥かに簡単。
また、テレッホーにきてやる。
103 ：
12：2001/01/05(金) 19:31
>>101 なかなかMFCに通じている方とお見受けした
包含クラスではなく多重継承としてインタフェースを実装すれば
pThisは不要だし、まるで多重継承で実装したときにコンパイラが
吐くようなオフセット計算されたポインタを
わざわざマクロ計算していることに意味を感じないだけど。
なぜそうまでして多重継承をかたくなに拒否するんだろ？ >MFC
デュアルインタフェースについては「テクニカルノート65」を見ろとか
言ってほしかった。
そんなのなくてもOK的な回答ではなく、解決策をしめしてくれたら
うれしかったのになー
みんながシリアライズに腹立たしさを感じているのは、
だぶん CDocument::Serializeについてだとおもう。
Serializeによるオブジェクトパーシスタンスのサポートと同時に
単なるファイル名によるセーブ/ロードのサポートもほしいってことでは？
CDocument::OnSaveDocument, CDocument::OnOpenDocument
をオーバライドすれば済むかもしれないけど、
ちょっとオーバーライドするには機能がありすぎ。
あと、俺的にはシリアライズされたファイルの中にクラス名が
そのまま入るというやり方はあまりいいとは思えない。
(へんなクラス名がばればれで恥ずかしいのよ)
Deserializeのときにクラス名からCreateObjectしているから
こうなるんだろうけどGUIDとかと対応付けさせればいいのにね。
VC1.0のころはいいなとは思ったけど
今となっては全体的に古さが否めない感じだけどどうよ？>>MFC信者
104 ：
禁断の名無しさん：2001/01/05(金) 21:17
>>99 >ルートオブジェクトCObjectがあるんで多重継承しちゃうと
>ルートオブジェクトが２つになっちゃうからでしょ。
virtual継承すればスパっと解決。
C++をなめちゃいかんぜよ。
105 ：
デフォルトの名無しさん：2001/01/05(金) 21:41
>>104 「テクニカル ノート 16: MFC における C++ の多重継承」を読め。
106 ：
デフォルトの名無しさん：2001/01/05(金) 23:11
すでにCObjectから仮想でない継承を受けているクラス
(CWndやCFileなどいくらでもある)複数を多重継承するには
どうしたらいいのかなぁ？そこから仮想継承ですか？
逝って下さい、さようなら
>>104の同性愛板からの人
107 ：
MFC信者：2001/01/05(金) 23:26
>なぜそうまでして多重継承をかたくなに拒否するんだろ？ >MFC
わからないな。一度だけどっかで読んだきがするが。
多分MFCInternal。
>デュアルインタフェースについては「テクニカルノート65」を見ろとか
>言ってほしかった。
そう逝ってやりたかったな（笑ひ）
CDocumentのシリアライズについては、当方勉強不足で
コメント不可能。許してくれ（笑ひ）
＞こうなるんだろうけどGUIDとかと対応付けさせればいいのにね。
まーね。でもわざわざGUID使ってクラス名と対応ずけるのも
めんどくさいな。
＞VC1.0のころはいいなとは思ったけど
＞今となっては全体的に古さが否めない感じだけどどうよ？>>MFC信者
あんたずいぶん昔から使ってるな。当方VC4から。
で、今のところ古さは感じないな。
まー漏れが厨房の可能性のほうが高そうだがな。
108 ：
104：2001/01/05(金) 23:42
>>106 >すでにCObjectから仮想でない継承を受けているクラス
>(CWndやCFileなどいくらでもある)複数を多重継承するには
>どうしたらいいのかなぁ？
話の流れに関係ない問題持ち出されても困るわ。
私が言いたかったのはＭＦＣがvirtual継承してればよかったのにね
ってことよ。
>さようなら
>>104の同性愛板からの人
同性愛板の名無しハンドルを知ってるなんて、アナタもお仲間かしら？
pizaでそんな怪しい名無しハンドルなんて簡単にさがせるよ
110 ：
MFC信者：2001/01/06(土) 00:12
>今となっては全体的に古さが否めない感じだけどどうよ？>>MFC信者
あたまだいじょうぶ？(藁ひ）
↑偽者？
いじめた人がイパーイいたからね。
もうこの名前でカキコはしません。
113 ：
。>：2001/01/06(土) 01:14
MFC1.0ってのは、MSC7だったかな？
オイMFC信者！おまえのちんこは長いのか？？
どうなんだ？とりあえず長いものは巻いておけ！
あとコンパイラオプションでアセンブラを吐き出して解析してみろ！
なぜＭＦＣがクソなのかわかるからな！わかったか！
わかったらいってよし！
>>113 日本語版はリリースされてない。VC++1.0でMFC2.0だったし。
でもまぁMFCってこの時代の苦し紛れの仕様引きずってる物も多いんだよな。
CSocket辺りとか。スレッド使うようになったらもっとましになりそうなん
だけど、互換性なくなるからできないんだろうなぁ。
116 ：
Virtual MFC信者~()：2001/01/11(木) 20:14
{
はい!!納豆ごはんにも毎日醤油とMFCかけて食べてます。
はい!!お風呂にもMFC入れて入ってます。
はい!!尿道の中にMFC入れても痛くありません!!!
はい!!毎日MFCの神に向かってお祈りは欠かせません。M氏に帰依します!!!
はい!!夜なんかMFCのソースでオナニーしますハァハァハァ。MFC萌え～
はい!!!彼女のマンコに指入れるよりwincoreに指入れる時の方が３倍速く白いものが出ます!!!
}これ位逝っときゃ満足すか
それは信者ではなくてフェチといわんか？
119 ：
へぼMFCプログラマ：2001/01/18(木) 22:22
うへー、全部読んだけど、
結局、MFCの何が悪いのかがよう分からん・・・
MFC無しではいられない体になってしまう麻薬性が
一番いけない。。。
そんなに簡単なのかい？
122 ：
デフォルトの名無しさん：2001/03/28(水) 22:03
,一-、
/￣ l | ／￣￣￣￣￣￣￣￣￣￣
■■-っ ＜ んなーこたーない
´∀｀/ ＼＿＿＿＿＿＿＿＿＿＿
＿_／|Ｙ/＼.
Ё|＿_ | / |
| У.. |
123 ：
デフォルトの名無しさん：2001/03/29(木) 00:18
VCLまんせー
124 ：
デフォルトの名無しさん：2001/03/29(木) 00:25
ＭＦＣ無しで何でも組めれば良いんだけど・・・
そうも行かない所が悩ましい。
125 ：
デフォルトの名無しさん：2001/03/29(木) 08:10
>>115 スレッド使うと互換性が無くなるってどういうこと？おしえてくん。
WTLはどうよ？ってスレ違いか。
127 ：
１：2001/03/29(木) 08:35
いろんな書き込みを読んでVCLも使ってみようかという気にもなっている
けど、BorlandCを買うのがちょいつらい（財布の問題）。でも結局クラス
ライブラリっていうのは設計者の思想に自分を合わせることに苦痛を感じ
るかどうかで良し悪しが決まるんじゃないの？BorlandがTurboCだしてた
とき、TVなんちゃらってキャラクタベースのウィンドゥクラスライブラリだし
てたけど、あれの使い勝手が良くなかったからちょっとBorland製クラス
ライブラリにはひいちゃうところあるんだよな。
128 ：
デフォルトの名無しさん：2001/03/29(木) 08:52
開発にVisualC++使うとしたら、MFC以外の選択肢には何があるのかな？
今時WindowsAPI直接呼ぶぐらいならMFC使った方が効率いいし、
VCLは開発環境が違うから論外だし、そうなるとATLでしょうか？
WTLは次のVisual.NET待ちですよね？
それとも、MFCを使うべきかどうかではなくて
VisualC++を使うべきではないということなんでしょうか？
129 ：
デフォルトの名無しさん：2001/03/29(木) 09:03
趣味で作る物はDelphやBuilderでもいいけど、周りに合わせるとやはりVCは外せない。
ケチ付けてるのは単にMFC使いこなせないからC++Builderに逃げただけだろ。
マイクロソフト製で無い時点でVCLが一般になることだけはないので、
次のVS待って出たらすぐにC#と使い分ければいい。それまではVBとVCを使い分ける。
複雑な物はMFCベースで、DirectX使うゲームなどはSDK直叩き。
130 ：
結論：2001/03/29(木) 09:05
プロなら全部使えるようにしとけ
131 ：
347：2001/03/29(木) 13:58
>>129 使いやすいと思うライブラリを
選択するのを"逃げ"というのか?
>>130 激しく同意。
全部使えて、その上で選択できる能力は欲しい。
って、これはＳＥの仕事になるのかな？ ＞選択
とか言いながら、僕はMFCよりSDK使った方が開発効率の良い
厨房駄目駄目プログラマーで～す。
鬱だ死のう。
> 複雑な物はMFCベースで
藁
134 ：
デフォルトの名無しさん：2001/03/29(木) 16:31
私そう使い込んだわけではありませんが、感想。
・MFCはAPIの低レベルラッパにしか見えませんでした。
あと直交性が低い部分があるのがうっとおしい。
・VCLはまだましですが、大規模プログラミングを考慮して
いないような気がします。
・SDKを直に使うとなんだか見通しが悪くなります。
（あのデカいswitch文はどうも・・・）
MFCよりもっとましな Win32用OOP向けライブラリって無いのかな？
135 ：
134：2001/03/29(木) 16:40
あ、どこかで見たMFC批判を一つ。曰く、
MFCだとObserverパターンがCDocument/CViewに結び付けられていて、
汎用性が下がっている。
CDocumentが Subject（JavaだとObservable）を継承してくれればよかったのに、と。
136 ：
デフォルトの名無しさん：2001/03/29(木) 22:41
> ・MFCはAPIの低レベルラッパにしか見えませんでした。
突き詰めれば、MFCの良いところはこれに付きるのでは？
どうせMFCだけでできることは限られているので、
Windowsで凝ったこと始めるとAPIを叩かないといけない。
だからWindowsAPIを把握した上で手抜きするためにMFCを使う。
低レベルラッパで良いんですよ。
>>129 VC高くて買えない・・・＞BCB買った
って流れでVCLなんだけど。
今は良いな。Learningとか安いもんな。
でも、VCとBCBの生産性を比較したらかなりの確率でBCBの方に軍配があがるよ。
138 ：
>>137：2001/03/29(木) 23:04
それは分かっているのですけどBCBが無いと何も組めない体になりませんか？
趣味プログラマならそれでもいいんですけど、結局使い分けでしょう。
RADやりたいのならVBの方がメジャーで相性良いですし、
先の事を考えるとVC#はDelph作った方が作ってるわけで、
RADの主流はC#になるでしょう。Windows上で組むのであれば、
最新技術のサポートの問題でMS製品でないと不安があります。
139 ：
デフォルトの名無しさん：2001/03/29(木) 23:12
>>134 もう自分で作るしか・・・(藁
今通信関連のプログラム作ってるけど、MFCのCSocketもVCLのTSocketも
いまいちなので、自分でシコシコ作ってるよ、オレは。
140 ：
>>139：2001/03/29(木) 23:16
大物作るとなると結局そうなりますね（笑
ウインドウ周りまで作る必要ないから
今のところMFCとの複合でやってますが。
141 ：
１：2001/03/30(金) 07:43
結局レベルの高いOOPSを求めず、便利なツールとして使うのならMFCって
便利ってことなんですね。
142 ：
デフォルトの名無しさん：