1 ：
デフォルトの名無しさん：
特にゲーム製作には全然使えん罠
文句があるなら使わなければいいだけ
会社じゃ使わざるを得ないよ。
昔作ったもののメンテしなきゃならんし。
それなりにまだまだ需要はある。
>>1のスレ立て行為を肯定するようなレスはやめれ！
7 ：
デフォルトの名無しさん：03/07/26 17:28
プログラマブル初心者なんですが
MFC使わなかったらWindowsアプリ作れないじゃないんですか？
WIN32APIでゴリゴリですか？
ATLでばびゅーん？
それとも商用ライブラリでも使ってるの？
ぺゾルトさんもMFC嫌いみたいね
VCLでゴリゴリです。
MFCにコリゴリです。
MFC のフレームワークって薄いイ皮で API ラップしただけじゃん。ホントアホらしい。
その点 VCL はすごすぎ。MFC とは天と地との差だよ。さすが今はなきヘジさんだね。
C# も素晴らしいがDelphi もまだまだ健在ってことだ。
13 ：
デフォルトの名無しさん：03/07/26 18:02
Java 最高!
皮が薄いほうが気持ちいいよ
>>1 MFC==ミットフィルダーセンター==ゲームメーカーの事。
つまり、ゲームを作るために生まれたんだ。
つまんねー。ごめん。
OWL の方が業界標準になった方が良かったのにね
19 ：
デフォルトの名無しさん：03/07/26 18:31
20 ：
デフォルトの名無しさん：03/07/26 19:07
猫さんのところいけ。
WIN32APIのが楽に作れる。
と、最近までは思ってたんだけどMFCにもゲーム作るときに役に立つクラスがあんだよな。
トラッカークラスとかほしいよね。
>>12 仕方ないよ。C++の限界だからね。
ボーランドもOWLで失敗しているし。
MFC使わない場合ってボタンクラスとか自作？
>>18 OWLよかったんだがなー
デバイスコンテキストのカプセル化なんか最高ですた
まぁブランドバカどもが無批判にMSﾏﾝｾｰした結果マイナーで終わったんだな
24 ：
デフォルトの名無しさん：03/07/26 19:32
>>22 猫でもわかるプログラミングってとこいくとわかるけど。
MFC使わない方が楽。なときが多い。
まぁいちいちマイナーなのを使って通ぶるｳﾞｧｶどもが無批判にﾏﾝｾｰした結果
マイナーで終わったんだな
Manko
Fuck
Chinko
いやらしいフレームワークやな
>>23 Win3.1 の頃は MFC vs OWL が互角だったが、
某が Win95 対応化のための BC の 32bit版開発が遅れに遅れたために
早くに対応した VC++ に OWL ユーザ流れたという話を雑誌で読んだ覚えがある。
BC5.0 のことかな？
BC5.0 前のプレ対応??の BC4.5 がバグってたせいという説も聞いたことがある。
詳しい真相を知ってる人は教えてくれ。
30 ：
デフォルトの名無しさん：03/07/26 23:49
WTL使えよ
MFC便利
Win32APIをラップした、解りやすくて、使いやすくて、速い、クラスライブラリ
を誰か作ってください。
33 ：
デフォルトの名無しさん：03/07/27 00:01
MFC便利
でも最近はATL/WTL
34 ：
デフォルトの名無しさん：03/07/27 00:02
>>32 そんなあなたにATL/WTL
薄いラッパーだからわかりやすいよ。
gtkは？
37 ：
デフォルトの名無しさん：03/07/27 00:19
tcl/tk
ム板でGUIライブラリ作ろうぜ
40 ：
デフォルトの名無しさん：03/07/27 00:40
41 ：
デフォルトの名無しさん：03/07/27 01:24
>>7の
プログラマブル初心者
っていうのは、流行ってるのでつか？
シャアウェアをインストロールしたらレジスターが
書き換えられてディスクトップがぐちゃぐちゃになって、
エキスプローラでホルダーをクィックしても動かなく
なってしまいました。どうすればレジスターを修復で
きますか？ ソフトはWindous95で機種はＢＭＷの
アクティバです。接続環境はフレッシュＩＳＢＮです。
ヤッホーやゴーグルなどの検索で調べても解らないので
ツーチャンネルの皆様、ご指導よろしくお願いします。
こういうの大好きな漏れ。
6月2日（月）
今日も息子はテストで0点を取ってきた。
本当に頭が悪い。 引き算が出来なくて立て続けに５問も間違える小学5年生がいるだろうか。
将来が心配。
6月3日（火）
息子の将来のことで夫と話し合った。
夫は興奮して、「もっと自分の子供を信じてやれ！」なんて偉そうに言ってる。
あなたに似たのよなんていったら、手をあげられてたかもしれない。
6月4日（水）
息子の部屋を掃除していたら国語のテストを発見した。
５回分のテストすべて0点。 しかも5枚とも自分の名前を間違って×がついていた。
息子は自分のことを「犬」だと思ってるのだろうか。
最近、夫の帰りが最近遅いのも気になる。
6月5日（木）
学校から呼び出しを受けた。もちろん息子の成績について。
もう学年が上がってからこれで４回目。 つかれた。
そういえば息子は、最近メガネが割られてたり、生傷が耐えなかったりしていたので
この機会に先生に尋ねてみた。 でも「うちの学校にいじめなんてありませんよ。」を
ただ繰り返すだけ。
もうメンドクサイ。ほおっておいた。 このまま見ぬふりをしていようとおもう。
6月6日（金）
息子がなにやら、大きな人形を拾ってきた。 どこかの薬屋さんのマスコットだろうか。
どこから拾ってきたのか問いただしても、「未来からやってきた」と言うばかり。
左頬を叩くと、狂ったように泣き叫び、その人形のおなかの辺りをまさぐり始めた。
「スモールライト～」と叫びながら右手を高々と上げる息子。
その右手を私の方に向けて、奇声を発しながらこっちを睨み続ける。 もう訳が分からない。
夫とのセックスがなくなってから、かれこれもう５年。
6月7日（土）
朝早く、「たけこぷたー」という息子の叫び声とともに目を覚ました。
次の瞬間大きな物音がしたと思ったら、庭で息子が倒れていた。
咲いたばかりのアジサイが真っ赤に染まっていたから、、、
また寝なおした。
夫は昨日、帰ってこなかった。
（＾＾）
(⌒V⌒)
│ ＾ ＾ │＜これからも僕を応援して下さいね（＾＾）。
⊂| |つ
（＿）（＿） 山崎パン
MFCにコリゴリです。
MFCでゲーム(ﾟДﾟ)
一ヶ月前から初めてＣというかプログラミング自体始めたけど
ＭＦＣめっちゃええやん。
49 ：
デフォルトの名無しさん：04/01/09 14:46
>>48 C++勉強しないでよく理解できるな。
MFCはクセが強すぎてイヤんなっちゃう。
コンパイラが通っても、実行時にエラー吐くのが多すぎ。
>>48 マジか？すげー。天才！
どうやって勉強したの？
>>50 隣に住んでるプログラマーのお姉さんに教えてもらった。
そろそろ別のことも教えてもらおうかな。ｗ
MFCっ娘萌え
C言語を独学し始めてから四ヶ月。
Win32APIしか使ってない。
MFCでやると、プログラミングが簡単になるのでしょうか？
>>53 C++をマスターしていれば少しはましになる。
.NET Frameworkだと劇的に簡単になるが。
.NET?
C#ってやつですか？
.NETのアカデミック版を買ったからはいっていたなぁ。
C++1はもっか勉強中です。
クラスを使うとプログラミングが簡単になるという事を理解しました。
>>55 C#じゃなくても出来るのが.NETの特徴だから、C++でも出来るが。
簡単さではMFCとは比較にならない。
59 ：
デフォルトの名無しさん：04/01/09 18:18
.NETっつーのは、そんな使いやすいのかー
>>59 っていうか逆で、それだけMFCが使いにくいってこと。RADじゃないから。
WTL使おう
62 ：
デフォルトの名無しさん：04/01/10 14:46
>>60 いま、VC++6.0+MFCで勉強してんだけど、
すぐにVC++.NETに移行すべきなんですかね？
まともなプログラミングをするにはMFCだけじゃなく
COMという高い山を越えないといかんわけですが。
今の.Netはアンマネージコード必須だからMFCとはまた別の厄介さがあるし
ゲーム制作にVCLは使えますか？
MFCって駄目駄目というのをよく目にしていたのでずっと敬遠していたのですが、
いざ使ってみるとかなり使いやすいじゃないですか。
笑えるくらいWTLがスルーされてるな
俺は好きだけどね
68 ：
デフォルトの名無しさん：04/02/04 23:22
っていうか
managedC++で終了でしょ
.NETの方がフォームも直感的に作れるし
なぜMFCはゲームに向いてないと思うのか・・
OnTimer()で30fpsのゲームを作ろうとしてる？
それなら、「猫でもSDK」でも解決しないよ。
winmainでぐぐって見れば？
VBより好きだぜ
OnIdleで、timeGetTimeとかつかって、60fps
72 ：
デフォルトの名無しさん：04/02/05 09:38
CStringとかふざけたクラス使うのヤダ
ＭＦＣ最高！！！
.NET 周りで使ってない。
よって MFC 健在
WTL！
DVD!
VCL使おうぜみんな！
OutputDebugString(AnsiString().sprintf("hoge value is %d", hoge).c_str());
とか書くの面倒だから嫌
79 ：
デフォルトの名無しさん：04/02/05 14:20
もう、MSがMC++に力入れないから
C#に行っちゃったよ。
どっちにせよ時期OSがああなった以上、遅かれ早かれ.NETは避けれないんだし
Win衰退を感じさせる場に及んで、始まってもない.NETに行くのは破滅パターン。
スレ違いですよ
>>80 売り上げが落ちたとは言え(しかも恐らく不正コピーの為)
Winの代わりになるOSが現段階で無いんだから、Winに付いて行くのは間違いではなかろう
まさか、一般ユーザーにLinux使えと言うのか？ｗ
林檎使えとか言うなら藁うぞ
煽りにマジレスとはおめでてーな
84 ：
デフォルトの名無しさん：04/03/18 04:37
破滅なんて味わったことないからな
この板が無職であふれかえるミライはみたくないよ
COMの次が.NET
COMと同じように.NETも社員だけに任せとけばいい
87 ：
デフォルトの名無しさん：04/03/18 13:40
>>86 いままでCOMに手をつけたことがないのか？
COMも知らずによくWindowsプログラミングができるな (激藁
毛嫌いしていたMFCをとうとう仕事で使う羽目に。
APIの世界へ帰りたひ・・。
90 ：
デフォルトの名無しさん：04/03/18 22:11
>>89 COMを学んでも理解できなかったのか？
おまえは何やっても無駄だよ (＾▽＾ｹｹｹ
使えるとこだけ都合よく使えばいいじゃん。
MFC便利と言えば便利だけど、どうも”痒い所に手が届かない”こと
がしばしばある。結局MFCの中からAPI呼びまくってたりする。
俺にとってはC++勉強用の教材かな。
93 ：
デフォルトの名無しさん：04/03/21 01:23
ゲームにはゲーム用のライブラリを作ればいい。
MFCはクラスライブラリの勉強においては
「反面教師」でしかないんだってね。
95 ：
デフォルトの名無しさん：04/03/21 02:04
既存のクラスを使うなら、ＭＦＣは簡単。
でも、ちょっとしたこと（フローティングボタンとか）作ろうと思ったら、
大変。モレはWindows3.1から開発してたから、ＭＦＣは便利としか思えなく
なってる。友人はＭＦＣよりもDelphiのほうが分かりやすく・作りやすい
と言ってた。彼から見るとモレは尊敬に値するんだと。
モレは単に我慢強いだけかもしれんが（ｗ。
Windowsアプリを作るなら、Delphiがお勧め。ムリして使うこたぁない。
WTLいいよな
>>94 VCLが使いやすいってのはただ単に、RADが使いやすいだけじゃん？
MFCはクラスライブラリの設計としてはそんなに悪くないんじゃないの？
あぁ、WTLは良い。
MFCは無駄に機能があるんだけど
俺が使いたい機能に限って無いとか
細かいところ弄れなくて使い物にならない とかで
あんまり使わなかったな
COMはフォームのコントロールの為に結構使ってた。
でも、メインはATL(のクラスだけ)やSTLやAPIだったね。
100Gets!
101 ：
デフォルトの名無しさん：04/04/12 09:51
MFCやATLは、.NETに対応しないんだっけ？
であれば、それらのソースを収束させるべき、というか、他に書き換えるべきかな。
> MFCやATLは、.NETに対応しないんだっけ？
それはもともとC++用のライブラリね。
だから.NETじゃなくてVisual C++.NETの話になる。
で、Visual C++.NETでもサポートされている。
103 ：
デフォルトの名無しさん：04/04/12 10:26
>だから.NETじゃなくてVisual C++.NETの話になる。
回答者がなんで勝手に質問を変えるの？
答えにもなってないし。
知りたいのはVC++じゃなくて、MFCとATL。
はぁ？ だからMFCやATLはVC++.NETでもサポートされてるって。
105 ：
デフォルトの名無しさん：04/04/12 10:33
107 ：
デフォルトの名無しさん：04/04/12 10:44
>>106 COMは反則でしょう。
MSがCOMをUNIXに移植すると宣伝しながら、
数年後に断念した（正式アナウンス）んだから。
109 ：
デフォルトの名無しさん：04/04/12 10:46
>>108 .NETアプリをMFC、ATLで作れるか？
という質問にＣＯＭのインターフェース作成で答える馬鹿、消えろ。
111 ：
デフォルトの名無しさん：04/04/12 10:48
108=110
ごめん、間違えた。
でも、質問に正確にというか、真正面から答えてくれない人は消えてくれると嬉しい。
この板を情報源にしてる自分としては。
> この板を情報源にしてる自分としては。
２ちゃんねるを情報源にするなよｗ
２ちゃんねるは質問する所ではありません。
ニュース速報代わりに使用するところです。
113 ：
デフォルトの名無しさん：04/04/12 10:53
>>112 >２ちゃんねるは質問する所ではありません。
>ニュース速報代わりに使用するところです。
勝手に決め付けないで。
本当に情報源として使ってるんだから。
現に情報源として成り立ってないじゃんｗ
115 ：
デフォルトの名無しさん：04/04/12 11:11
いまどきMFCか
117 ：
デフォルトの名無しさん：04/04/12 11:18
違うだろ。
MFCをどう捨てるかに迷うんじゃないか。
ばっさり捨てるか、ライブラリとして使えるとみるか。
すてないとWinFXに移行できないよ
捨てるには、
社内にそれなりのアナウンスが必要。
MFCを直でWinFXコンパイル出来ませんよ、とか。
120 ：
デフォルトの名無しさん：04/04/12 14:15
ライブラリくらい自分でつくれよ～
MFCなんぞ使うなよ～
と、言ってる俺は、MFCなんぞ使ったことがない。
いつもAPIをガリガリ…ガリガリ…
>>120みたいなこと言う奴に限ってCやC++の標準ライブラリは使ってるんだよな。
ライブラリを否定するならそれらも使うなと。
そういう問題じゃない
>>121 >>120 クラスライブラリ >>>>>>>>>> 関数ライブラリ=120
しかたねーじゃん、ハードの問題でMFCつかえないんだから。
使えないのに、勉強する気にならん。
じゃあスレ違いだな。氏ねよ。
ごめん俺死んじゃった
127 ：
デフォルトの名無しさん：04/06/16 00:29
IDﾁｪｯｸ
256get ∧＿∧
∧＿∧ （´<_｀ ） ん、どうした兄者？
（ ´_ゝ`） / ⌒i
／ ＼ | |
/ /￣￣￣￣/ |
＿_(__ﾆつ/ 2ch / .| .|＿＿＿＿
＼/＿＿＿＿/ （u ⊃
∧＿∧
∧＿∧ （´<_｀ ） 128だったな兄者…
（*´_ゝ`） / ⌒i
／ ＼ | |
/ /￣￣￣￣/ |
＿_(__ﾆつ/ 2ch / .| .|＿＿＿＿
＼/＿＿＿＿/ （u ⊃
転職の時にMFC使えると有利になるかな？
よく求人にVC++を使える人を歓迎って
書いてあるけど・・・
なんだかんだ言っても、ネイティブアプリ作るとなると、
まだまだ必要なんだよな。
API直叩きとどっちが楽なのか、時々わからなく
なるけど・・・(´･ω･`)
次はActiveXが消えると思う
MFCって、Win32プログラムをC++で束ねるのに使うヒモみたいなもんだよね。
何がおかしいって、C++のプログラムでここまでマクロ満載ってのがすごい。
まぁ、中身がパカパカ見れるからまだ何とかなるが、デバッグのときに
どこまで行くんだってぐらいにソース開きまくるのってどうだろう。
134 ：
デフォルトの名無しさん：04/09/23 17:08:50
これから新規に中規模アプリケーションを開発するんですが、
やっぱりMFCよりも.NETを選択した方が賢いでしょうか？
でも.NETは起動がもっさり＆アンマネージコード必須なのがちょっとひっかかるんですが。
135 ：
デフォルトの名無しさん：04/09/23 17:32:19
中規模ってお仕事で？
個人開発です。
将来の定期的なバージョンアップを視野に入れると.NETが有利な気がしますが、
.NETはまだちょっとしか触ったことがないので不安です。
MFCが使いやすいんならMFC使えば？自分がどっちでやりやすいかが問題だろ。
MFCで作ってたらそのビルドが使えなくなるっていうんなら変える必要もあるけど
５年くらい先までなら確実に現行OSのシェアが半分あるだろうから、その点を問題
にして変えなきゃならないということはないと思うが。
現状では積極的に.NETで新規開発するメリットはあまりなさそうですね。
C#2.0になってLonghornがでてきたら変わるかもね
まぁすくなくともあと5年くらいはMFCは現役かと
先にWin32 APIでプログラム始めたんで、MFCを使うようになって便利になったけど、
Win32 APIに対応するMFCのメソッドはどこにあるのか、はたまた、ないのかがわかりにくい。
結局、MFCのソースをgrepしてたりする。
あと、FindFile APIのラッパが CFileFind なんて File と Find が逆になってるのはいぢわるなんですかね?
漏れもMFCの後にC#.NETに移ったクチだが
感動的なぐらいコーディングが楽だぞ。
速度上の要求がどうしても厳しいなら、MFCの
方がいいかもしれないが、そうでないなら.NETの
方がはるかに楽。
強いて言えばWin32API使う時に煩わしいのが難点かな。
>>141 C#バンドルのライブラリが充実していたからそう感じたのであって、
数々の有益なライブラリで武装したC++より優れているなど有り得ないと思うのだが。
まさか、「iostream/STL/ATL/MFCだけのC++」と「C#」を比較してないよね？
はぁ？
OTL
はぁ？
はぁ？
147 ：
デフォルトの名無しさん：05/01/09 02:21:37
はじめてMFCの勉強してるけどわけわからん…
これはホントに普通のC++のフレームワークなのか？
VBみたいなところもあるし、へんなマクロがたくさんあるし、
ウイザードの動きがよくわからんし…
>>147 MFCというのは元々C++ではなくCでWindowsアプリを
「プログラミングWindows」の流儀でゴリゴリ書いてた人が
抵抗なく使えるようにすることを目的に開発されたライブラリだから
メジャーなオブジェクト指向のライブラリとしては
史上最低のオブジェクト指向度を誇るらしいよ
実際APIの薄っぺらなラッパでしかないクラスも多いし
149 ：
デフォルトの名無しさん：05/01/09 02:36:48
（´･∀･)つﾍｰﾍｰﾍｰ
MFCで気に入らなかったのがダイアログベースのFormViewだったなぁ。
手軽に使えるのはいいけど見た目がじみすぎた。
.NETのWindows Formのような手軽で表現力の高いViewが必要だったのだと思うよ。
じぶんもMFCからC#2.9に移ってるが、コーディングマジ楽･･･
まぁらくなのはインテリセンスに負うところが多いいが、メッセージがイベントに変えられてるところが実にエレガント
あのうんこマクロとはだんち。
まあQt/KDEが最強なわけだな。
QGLクラスもあるしな。
MFCで作れることになってる高度な複合ドキュメントがほとんど必要に
されなかったことが敗因だと思う。
UIなんてFormViewで十分だったからね。見た目が地味なのは同意。
154 ：
デフォルトの名無しさん：05/01/12 11:22:56
そうだなあMFCはカローラクラスの満足度を目指しているのでは
70点主義
残りの30点を補完するにはAPIごり書きしかないしね
にしてもJAVA環境から比べれば断然いいなVC++
>断然いいなVC++
VC++というのとMFCというのと違う罠。
MFCをいいとは言えない。
Win32＝自由度高い→ど素人では、でたらめなものしか作れない。
MFC＝制約多い→ど素人では決まりきったものしか作れない。→嫌気がさす。
よほどの天才以外は、初心者にはMFCやらせた方が将来的に伸びると思う。
MFCはWin32と比べて嫌気じゃなくて、
他クラスライブラリに比べてなんだけど。
どちらかというと、Win32に毛が生えた程度でしかないことがMFCの問題点。
まともなクラスライブラリ利用に比べて伸びが抑えられる悪寒。
159 ：
デフォルトの名無しさん：05/01/12 15:32:03
本当に勉強したいなら、多少遠回りにはなっても、
コンソールアプリで言語仕様覚える→猫あたりを読んでWin32の仕組みを覚える→C#などの
ライブラリ物に挑戦
がいいだろうな。何も分からずライブラリ使うのとWin32の理屈が分かりつつ使うのは大違い。
猫はサンプル見るのには使うけど、あれで勉強するのは無謀
基本わかってて実装方法を調べるという使い方だな
あとC#は別物なので混同しないように
大筋良さそうな内容だが、
>C#
こいつ、というか、ＣＬＩのせいで中が見えないだけだが。
中の人が見えるライブラリにすれば、Win32APIコールまでクラスライブラリから読めて万事ＯＫ。
VSワールドは捨てれ。
VSワールドの悪。
VB、VC++/MFC、C丼/CLI
163 ：
デフォルトの名無しさん：05/01/12 20:25:03
時代はeclipseでD言語にゃるめ～
C#なんて使ってる香具師いる？
NetFramework入れないと動かないだろ
Win32API呼べたっけ？
間接的に呼んでるということか
.NET Framework は Win32 のラッパだよ。
169 ：
VC6：05/02/06 11:53:07
なんでdynamic_castをつかうとwarningがでるんだ？
設定が悪いから。自業自得。
MFCも当初はOWLのようなオブジェクト指向のライブラリだったらしい
けどな…
プロトタイプを作ってみたら当時のマシン/OSでは遅すぎて話にならん
という事で却下されて、今のMFCの形で作り直されちまったそーな。
「MFC Internal」だったかでその辺の経緯が出てたよ。
OWLとMFCでは出来が違いすぎたからな
>MFCも当初はOWLのようなオブジェクト指向のライブラリだったらしい
けどな…
M$にマトモな設計は元から無理。
ｺﾞﾐｱｰｶｲﾌﾞの塊のVSにマトモな設計のMFCが入ってる方が違和感。
またﾃﾞﾑﾊﾟが来たよ。
174みたいにMFCを擁護する椰子の気が知れないな
173みたいな電波を擁護する椰子の気が知れないな
177 ：
デフォルトの名無しさん：2005/04/03(日) 17:50:31
ゲーム製作にMFC使ってる奴なんているのか？
まだDXライブラリでも使ってる方がマシだな
あれだけ儲けてる会社の技術者達なのに
どうしてこうなってしまうのかが不思議
MFCだけでなく全般のソフトにしてもね
組織が官僚化しちゃってるのかな
>>178 儲かってるのと社員の質は別。
寧ろ反比例してんじゃないかと思う今日この頃。
ゲームメーカーのナムコでは、商品がヒットすると大きなボーナスが出るシステムを導入した結果、
既存ゲームの続編開発に希望者が殺到し、革新的なクリエイターが消えてしまったとNHKでいってた。
やっぱBCBとかDelphi使ったらMFCには戻れないだろ。
182 ：
デフォルトの名無しさん：2005/04/26(火) 02:30:31
soudemonaiyo
183 ：
デフォルトの名無しさん：2005/04/26(火) 13:36:35
DirectXともSDLとも相性が悪すぎだ。
MFC自体あまりできのいいものでもないのだが、
やはりお気軽にGUIが作れるというのは捨てがたい。
>>176 DirectXとかでゲーム作ってるときとかでも、内部のパラメータを微妙にいじくるのに便利。
たとえばスライダーコントロールとか。まあ、開発を促進するためのツールとしては一定の
使い道があるけど、ゲームの一部になることはないんじゃない？
重いし
>やはりお気軽にGUIが作れる
( ﾟдﾟ)
(つд⊂)ｺﾞｼｺﾞｼ
(；ﾟдﾟ)
(つд⊂)ｺﾞｼｺﾞｼ
_, ._
（；ﾟ Дﾟ）
MFCのソースコードには怨念を感じる
余計な動作しすぎなんだよあれ
団子クラスライブラリになってるために派生し難くくて、
画面にべたべたコードを書かざるを得ないよね。
エラー時にどかーん、と出るダイアログサイアク。
エラーファイルと行数がクラスライブラリの中じゃないか。
そーじゃなくて、ふつーのコンパイラの如くエラーコードでデバッガが止めてトレース出来るようになってて欲しいんだよ。
まぁそんな優しい作りをゲイツ一家に期待するだけ無駄ってもんだ
○○よ、
MFCの悪口言うのは勝手だけど、経験なしのやつが言うなよな
初めて使ったときに思ったこと。
「これ何言語？」
そうそう、ウィザードが巨大なきちゃないコードが吐き出す。
コードジェネレータなら仕方ないとあきらめるけど、一応クラスライブラリでしょ？
クラスライブラリが汚い部分を中に隠して、楽々差分コーディングできるのが普通なのにぃ。
〃〃∩ _, ,_
⊂⌒（ `Д´） ＜ ヤダヤダ！
｀ヽ_つ ⊂ノ
ジタバタ
〃〃∩ _, ,_
⊂⌒（ `Д´） ＜ ヤダヤダ！
｀ヽ_つ＿_つ
ジタバタ
_, ,_
（`Д´ ∩ ＜ ヤダヤダ
⊂ （
ヽ∩ つ ｼﾞﾀﾊﾞﾀ
〃〃
〃〃∩ _, ,_
⊂⌒（ つД´） ＜ ヤダヤダ
｀ヽ_ ノ ⊂ノ
ｼﾞﾀﾊﾞﾀ
∩
⊂⌒( _, ,_） ＜ ヤダヤダ…
｀ヽ_つ ⊂ノ
ﾋｯｸ...ﾋｯｸ...
∩
⊂⌒( _, ,_）
｀ヽ_つ ⊂ノ zzz…
>>189 君の言う「ふつーのコンパイラ」が何だか知らないが
VC++ が入ってれば、そのダイアログから
デバッガ起動すればいいジャマイカ
何がヤダなんだよ！？
197 ：
デフォルトの名無しさん：2005/05/19(木) 23:07:45
MFCってさ、ひそかにコードビハインド実現してないか？
あのリソースファイル。
198 ：
デフォルトの名無しさん：2005/05/20(金) 03:16:49
>>1 MFCよりゲーム製作に使えるライブラリってあるか？
DirectX+MFCに勝てるようなソリューションはなかなかないと思うが
( ﾟдﾟ) …
Qtでいい。無能はMFCをたたえる。
CDialog１つに対してresource.hとrcファイルがあって、
プロジェクトをダイアログ単位の部品クラスに分割できれば、
まだ使えたようなｷｶﾞｽﾙ
202 ：
デフォルトの名無しさん：2005/06/25(土) 10:41:38
配属が変わったチームリーダーにMFC厨がいて、
「MFCとの相性が悪いから、STLは禁止だからな。vectorとかのコンテナは全部 CPrtListに、置き換えろ」
とか言ってる馬鹿が居るんですが、どうしたら説得できますか？
（もうSTL無しでプログラムが書く気がしない）
>>202 君を含めてソフト屋は思い込みの激しい奴多いから説得は無理とあきらめろ。
それがチームの方針なら従うしかあるまい。
そのチームリーダーですが何か？
>>202 色々考慮しておく。
205 ：
デフォルトの名無しさん：2005/06/25(土) 12:37:54
MFCなんてまだ使われてるのか。
なんで.NETに移行しないの？
206 ：
デフォルトの名無しさん：2005/06/25(土) 12:42:31
.NETでMFC使ってるよｗ
207 ：
デフォルトの名無しさん：2005/06/25(土) 12:50:18
まだMFCって使われてるの？
MFC の阿呆なコンテナ使うのは阿呆だけ。
麻雀格闘倶楽部の事かと思った・・・ってぐらい疎遠になったな。
MFCしか知らないんだからしかたないじゃん！！
211 ：
デフォルトの名無しさん：2005/06/25(土) 17:11:03
CListって多次元配列できないじゃん
いまだにMSがMFCをサポートしている理由を述べよ。
Win32のGUIを扱いやすいのがMFCだからじゃん？
データのコンテナにMFC使う奴（＝プロジェクト）は糞だが
VC6についてるSTLを使おうとする奴の方が糞だろ
VBとかで作ればすぐできるのに、
なんでみんなVC＋MFCで作ろうとするの？
時間の無駄。
どっちもどっちだろ。目くそ鼻くそ
>>214 つか、VC6なんてもうね…そもそもコンパイラがね…つд｀)
>>215 VB知らないから。
見た感じVB使ってもたいしてVCと変わらない印象がある。
それならランタイムライブラリ要求されるVBより、VCの方がお得感
があり、イマイチVBやろうという気が起きない（MFC**.dllは98以降
標準だし、95でもまず入ってる）。
いやいや、それがね MFC71.dll が Win2000 には入っていないときもあるのさ。
オレね VC++7.1 のデフォルト設定でコンパイルして客先に流したら
動かねぇって文句いわれた。
ま、客先に起動時のエラーメッセージ読んでもらったら、
すぐに気づいて MFC を埋め込んでリビルドしたけどね。
ちょっとアセっちゃたね。
おれも VB 知らね、使う気にもなんねぇ。
熟練工だったら VB で作るより MFC のほうが絶対に速い。
( SDK との勝負だったら VB のほうがだんぜん速いとは思うが...)
MFC71.dllはXPにもはいってないよ
>>215 あんなポインタも無い言語・・・(；＾ω＾)
>>215 あんな元インタプリタ言語(´,_ゝ｀)
ポインタはいらねーよ
ポインタ無かったら汚いインデックス貼って配列まわさなきゃいけないじゃん
まぁSTLならイテレータあるけど
MFC？POSITION？（禿藁
ていうかVBまで飛んでかなくてもC#でいいっしょ
質問するとMSDN読めってのが定番だけど、いきなりMSDNだけで
所定の動作をさせようと思ってもムズイ。一度使ったことのある機
能であればMSDNすごく使えるけどね。
もう少しチュートリアルをシンプルに分かりやすく出来ないもんかね。
MFCはソースコードのためだけに存在する
Windowsのバグが分かる卑怯さ。
てかwin32の方を直せよ
それは出来ない。
なぜならそれを直すと、動かなくなるソフトが出てくるからだ
だから2とかExとか出てくる訳だな
てｓｔ
232 ：
デフォルトの名無しさん：2005/09/13(火) 14:45:55
きんもーっ☆ MFC
>>230 方針としてダタしいよ。
Ｗｉｎが受け入れられたのもそれが主因
RADつーるつくろう
今までwin32APIとか、.netとか触ってて、
昨日初めてMFCに触ってみたんだけど、これ、深いマクロだらけで訳分からん…
エラーが出て、エラーメッセージ見てもググらないと理解不能なのが多いし
ヘッダーの#includeの順番次第ではエラーが出たりとか、もう発狂しそう
皆さんは初めての時MFCをどうやって学んだんでしょうか？
AppWizard
>>235 >>エラーが出て、エラーメッセージ見てもググらないと理解不能なのが多いし
その通り。
だから一つずつMSDNやWeb上の情報を見ながら覚えていくのだ。
エラーメッセージも、API、クラスの使い方も。
Wizardって魔法使いって意味だからね
>>237 で、解決策がふつーに考えればメソッドだったりする筈だが、
色塗るにもWin32APIの力借りてカラープロパティさえ無い、と。
何このラップ出来て無いクラスライブラリ、って感じ。
MFCのソースを使って
Windowsのバグを回避したら訴えられるのだろうか
241 ：
デフォルトの名無しさん：2005/10/29(土) 19:29:54
もしかしてＭＦＣって、Windowsプログラミングを少し理解しててC++をかなり詳細に知ってる人間にとってはすごい便利なものじゃない？
カプセル化が中途半端なので、更にMFC自体の仕様も十分に理解してる必要がある。
＞２３５
順番に抑えていくうちに、自動生成のソース全部意味分かるようになったよ。
それとともに、the APPというプログラム開始実体から、うんぬんかんぬんやってメイン呼ばれて行くかも分かったし、
ランタイムとその周辺も分かってくるようになった。
それと、今まで、インクルードやDefineやクラスやメンバなどの定義位置がいかにあやふやだったかてのが分かった。
ただ、やっぱりクラス間での参照渡しは、なかなかつらいもんがある。
それと、
逆に、マルチフレームやスプリッタなどのいわゆる複数画面は、
WIN32アプリの方がCALLハンドラがアミダ状態で嫌んなる。
ホント実用的な画面設計に関しては、楽だよＭＦＣは。
メイン関数も無いし、どこからどういう順番でハンドラが
呼ばれるのかさっぱり分からなかったが、とりあえずそういうものだと
思うことにしてしばらく格闘したら分かるようになった。
＞２４５
少し忘れかけてた部分あって、もう一度調べてみたが、
まず、メインが始まる前に見に行くものがある。(includeとかマクロとかstaticとかグローバルオブジェクトとか)
で、CREIApp the Appというのが見つかる。
そこでCREIApp::CREIAppのコンストラクタ、いやいや、これは派生クラスだから、
CWinApp::CWinAppを見に行く(CWinAppの定義はAfxWin.hにある、コンストラクタ実装はAppCore.cppにある)
そして、次にCREIApp::CREIAppを見に行くが、通常こいつは空だ
いよいよWinMainだが、MFCのWinMainは変わっていて、_tオプションがついて_tWinMainになっている(実物はAppmodule.cppにある)
そこには、
return AfxWinMain(hInstance, hPrevInstance, lpCmdLine, nCmdShow);
とだけ書いてある。要は、AfxWinMainを暗に呼んでいる、こいつがどこにあるかというと、Winmain.cppにある)
このなかで、CWinAppのInitApplication、次にCWinThreadのInitInstanceが呼ばれている。
継承関係はCWinThread>CWinApp>CREIAPPで、どちらも仮想関数になっていて、virtual属性が付いている。
ということは、実際呼ばれるのは、たどっていくと、派生末端のCREIAPPのInitApplication、InitInstanceの順に呼ばれることになる。
ご存知の様に、InitInstanceではRunTimeが施されていて、Doc、Frame、Viewが関連付けられている。
話し戻って、その後AfxWinMainは何やっているかというと、Win32アプリと同じようにRun関数でメッセージループにして、半無限ループにしている。
やべーちょっと使ったら息子から我慢汁溢れてきた
これＭＦＣマジでスゲーから
自作のウインドウライブラリなんてカスだわ
こんなすばらしいモノがあるのになんでＶＢやＮＥＴなんか開発したのかわからんね
ＭＳＤＮでクラスライブラリにさらっと目を通せばあなたも今日からＭＦＣマスター。
.NET で全てなかったことにされて
Windows Forms を１から用意しなおしたことからも
MFCがクソだったことはMSすら認めてる事実。
誰かさんの.netにだけMFCが付いてこなかったようだね
クラスとかがよくわからん俺にはMFC使う人は尊敬する
俺はSDKでごりごり書くことしか出来ないよ・・・
MFCが難しいのはクラスとかが原因じゃないと思う
リファレンス無しでソースだけ見ても全く理解不能なコードだったりする辺りが
あまり優秀な開発者を回せなかったんだろうな
JavaのSwingのコードにもそれを感じる
× を回せ
○ が居
255 ：
デフォルトの名無しさん：2005/11/07(月) 11:04:17
>MFCがクソだったことはMSすら認めてる事実。
内容は正しいけど、認めてるというのは知らなかった。
表向きに認めているソースきぼんぬ。
裏的にはMFCの次にATL/WTLが出たり、
GUIライブラリとしてM$社内でMFCが使われて無いという事実だけで、
十分だけどね。
256 ：
デフォルトの名無しさん：2005/11/07(月) 14:52:46
ＶＣ＋＋６を使ってますが、
メモリリークの箇所とかソースファイルを特定する方法を
教えて下さい。
MFCって処理速度はどうなん？
ActiveX使わなければ高速だろ。
MFCでActiveX使わないと寂しい画面になるお。
MFCでActiveX使うってダイアログベース?
MFCってコマンドライン専用？
確かにVC++はテストプログラムの場合ダイアログは皆無で、コマンド系ツールを良く見かける。
263 ：
デフォルトの名無しさん：2005/11/14(月) 16:25:14
264 ：
デフォルトの名無しさん：2005/11/14(月) 17:32:47
>>264 その777,774も含めてクラス間の直交性ってナニ？って質問じゃないの？
数学や物理なんかで直交性ってのはイメージとしては互いに独立で相互依存がないような関係を差す
＜CArrayからCListに変えた場合に書き直すコードが多い＞即ち＜非直交＞というのは短絡ではないかと？
コンテナなどで互いに独立性の高い要素に分解して設計する場合に直交性の話をするけど、クラス間の直交性
というと、相互に干渉しないで共用できる場合に言うような気がする。
ま、C++も最近調べ始めた人間なのではずしているかも知れないがな
266 ：
デフォルトの名無しさん：2005/11/18(金) 07:24:12
いやーいいわＭＦＣ。
今までの努力はいったいなんだったのか
なんではじめからこれを使わなかったのか
今まで１ヶ月以上かかっていたことがＭＦＣだとたったの３日
青空に浮かび風の趣くまま漂う白雲のような自由を私に感じさせるナイスライブラリ
ＭＦＣ is 最高
267 ：
デフォルトの名無しさん：2005/11/18(金) 07:30:15
MFCに市場価値がないならExpressに付けるがな。
ここ見て.NET面白そうじゃんと思って作ろうと思ったら
ノートンに「悪質なスクリプトじゃ」と怒られました。
旧VB6系コンパイラをV$から外したように、
MFCをユーザーからやめさせたくてもExpressから外すだろ。
というか、どっちかというとV＄はそういう場合ばかり。
ＭＦＣってNETよりうまくできてるよ
ＮＥＴは素人向けすぎてどうもいかん
両方使ったこと無いが、.NETとMFCって比較すべきものなの？
.NET = 言語非依存なライブラリの標準的規格(MS談)
MFC = ライブラリ
かと思ってた。
>>271 正確には
・C++ & MFC & Win32 API
・Managed C++/C# & .NET Framework
の比較でしょうね。
クラスの名前にCをつけるのが嫌い
あほの子じゃないんだからそんなことしなくてもわかるよ
しかもクラス名のイニシャルＣを勝手に削りやがるし
うっかりするとわけのわからないヘッダファイルになってしまう。
275 ：
デフォルトの名無しさん：2005/11/19(土) 11:58:48
あほの子じゃなければ、自分で作るクラスの名前もファイル名も自分で
設定すれば良いんじゃないのw
>>274 突然 IDE (の Wizard) の話をし始めるとは、あなたあほの子ですね。
つまんねーよハゲ豚メガネどもめら
MFC(Microfost Fucking Class)
280 ：
デフォルトの名無しさん：2005/11/19(土) 21:38:14
VisualＣ++6.0とJavaはどのような繋ぎ方があるのですか？
或いは、.NET(C++,C#)だとどうなんでしょうか？
280は馬鹿
.NETは使ったこと無かったのですが、.NETFrameworkでは全て
「IL (Intermediate Language)と呼ばれる中間コードにコンパイル」
なようですね。そして、
・C#、Manage C++、VB.Net、JavaScriptが.NETFramework上で扱える
・.NET Framework では、これらすべての言語で同じライブラリを利用できるし、異なる言語で書かれたプログラムを呼び出すことが出来る。
ということなようです。
ただ、.NETFrameworkにJavaが入ってないのですが、これからどうなるんでしょうね。
現時点でJavaScriptが入ってるということでなんとかなりますか。
脱線失礼しました。
283 ：
デフォルトの名無しさん：2005/11/20(日) 00:56:40
それと、C++BuiderとJBuiderもお互い呼び出すことができるらしいのですが、
.NETとどちらのどの辺がいい等あったら、レスお願いします。
その前に、話が流れたとはいえ、他スレに逝けと言われそうですねw
>>282 >ただ、.NETFrameworkにJavaが入ってないのですが
その為にC#なんてシロモノをでっち上げたわけだが。
え？
J#もあるしJScript.NETもあるんですが？
286 ：
デフォルトの名無しさん：2005/11/20(日) 07:57:43
それにしても、Managed C++はきもい。ガーベッジコレクション機能１ついれるために、
言語仕様が全体に渡って継ぎはぎだらけ。
おまけに、オブジェクトに__gc修飾 がついているかどうかを常に
気をつけなきゃいけないんだったら、いらないよそんなの。
まだ、deleteするのを忘れないようにするほうがまし。
なぜここｋでmanagedの話題がでるのかわからんが、
入れるならきちんと標準化委員会でガベッジコレクションの仕様を定義してほしいのう
>>286 VC++ 2005のC++/CLIについて一言。
VS2005が出たら、.NETではC#からC++にメインを移そうかと考えてる。
いいんじゃないの？
両方使えるのが理想
>>286 あれは既存ソースの移植用にあるものとみたほうがいいだろ
そうじゃなきゃC# で作ったほうがﾊﾔｽ
だからVBの代わりだってば
>>285 ああ、J# には驚いた。COBOL# とか Eiffel# と同程度の愚行だ。
(切り捨てて困る程、J++ ユーザなんて居たのか？)
>JScript.NET
Java の話をしている時に、それを引き合いに出す意味が判らない。
>>293 その辺は単に.NETの汎用性っつか言語非依存性を強調するための
プロパガンダでしょ。
>言語非依存性
超鳴り物入りだったのに、
ﾌﾞﾋﾞﾁｭｳがﾌﾞﾋﾞドトネトさえも使えない現状を見ると、
全く持って無意味だったね。
296 ：
デフォルトの名無しさん：2005/11/30(水) 02:54:33
MFCを使わずにWIN32だけつくっているひとは
なぜにいつも ”ごりごり” なんて言葉つかうの？
ソースが１０万行以上の中規模プロジェクトをすべてWIN32だけで
書いたのなら確かにごりごり書いている気はするが、
所詮、１，２万行程度のサンプルアプリを書いているだけでしょｗ
>>296 「MFCを使わずにWIN32だけつくっているひと」が
「いつも ”ごりごり” なんて言葉つかう」が事実かどうかも知らないし
ましてやその理由など本人に訊けと。
枕言葉
ごりごりとWIN32
もっさりとJava
最初はMFCを使っていた。
確かに初心者にはツールバーなど
便利な基本機能がついているのはうれしかった。
しかし、フリーソフトとして公開するとき、
ランタイムライブラリの問題など凡用性に問題が
いやになった。プログラム単体で動くようにしたかった。
SDKはそれが可能だし、すべて自分で作ってる感、
全処理ソースを目で確認できる爽快感。
MFC、最近は気持ち悪くて使えん。
MFCのソースみるといろいろと参考になる
MFCのDLLぐらいで嫌がってたら
インストーラ使うソフトはもちろん.NETも使えないな
304 ：
デフォルトの名無しさん：2005/11/30(水) 19:21:12
サンプルっていうかプロトタイプじゃね？
ある程度以上の規模だと最初にざっとしたものを
つくってしまう。
2万行程度ならそんな感じじゃん
凡用性…
嫌気がさしたんだろ
凡用性…
凡人なのか？
MFCのライブラリを添付するインストーラは結構あるね。
印象に残ってるのは、ATIのCryエンジンデモプログラム。
お前はいつ、どこでGUIを使ったのかと小一時間（ry
312 ：
デフォルトの名無しさん：2005/12/03(土) 15:35:44
MFCをGUIの為だけと勘違いしている人がいるんですけど
スルーでOKですか？
>306,308
確かマルチスレッドにするとＤＬＬにせざるを得ないじゃなかったっけか？
Σ（☉◇☉）
>>312 GUI を使わない MFC になど
糞ほどの価値すらないと思っている俺に
是非解説して頂きたい。
MFCのGUIにもそれほどの価値があるとは思えんが
afxwin.h使わないとなると、
あの糞極まりないコレクションクラスだの、古臭いDAO/ODBCラッパーだのか……
激しくいらんわな。
MFCに嫌気がさした人は当のMSの人たちでしょ
320 ：
デフォルトの名無しさん：2005/12/04(日) 10:51:46
MFCの有用性をトータルで上回るクラスライブラリがあるならねえ。
ないし。
321 ：
デフォルトの名無しさん：2005/12/04(日) 11:17:36
.NET Framework
322 ：
デフォルトの名無しさん：2005/12/04(日) 11:43:49
.NETは別のものだし。
>>324 CWindowImplなんかはWTLのメッセージクラッカと併せて使えると思うが。
326 ：
デフォルトの名無しさん：2005/12/04(日) 14:24:27
今時Ｃ＋＋なんてはやんねーよ
327 ：
デフォルトの名無しさん：2005/12/04(日) 14:48:21
はやりすたりの浮草稼業じゃないし。
C++プログラマにすれば、むしろ流行じゃないほうが得だったりする。
>>326 C#厨ｷﾀ━━━━(゜∀゜)━━━━！
MFCでもCOMを使う、あるいは、COM使うべき状況に置かれることは多い。
よく見かけるのだが、
MFC経由でCOMを使うことには無頓着で、
ATLがCOMを使うことに拒絶反応を示す理由がわからない。
そもそもATLの基底ウィンドウクラスはCOMと関係なくビルドできる。
ATLでGUIを書くのは大変だろう。
VCL最強ってことで。
WTL使っていいなら、少しは考えるけど。
でもやっぱﾏﾝﾄﾞｸｻ
俺は、Spy++とかでウィンドウクラス名を見ただけでMFC使ってるのがバレバレになるのがイヤでWTL使ってる。
なんだよそれｗｗｗ
見られると恥ずかしいという点においては同意する
ことごとく「Afx:」のプリフィックスで始まるウィンドウクラス名。
有償アプリでこれを見てしまうとその会社のレベルを疑ってしまう自分。
ま、実際はMFCをちゃんと使いこなせてる感じだし、これをもってレベルを計るのは間違いなんだけどね。
しかし当たっていることが多い
MFC でまともに動くモノを作れてるなら
寧ろ褒めてあげて下さい。
んじゃ、商用のWinアプリって何で作られているのが主流なの？
VCL?
たまに商用系で某アイコン＝VCL見るお。
某アイコンのOk/キャンセルの方が恥ずかしい。
>>324 #define _ATL_NO_COM_SUPPORT
exeのプロパティ見て、
バージョン情報のタグが出るのがMFC
出ないのが某製
であってる？
VC++を使っていようとBCB(/BCC)を使っていようと（もちろんそれ以外を使っていても）バージョン情報は埋め込める。
確か、某が公開したexeから使用しているVCLクラスを取得するツールがあった筈。
348 ：
デフォルトの名無しさん：2005/12/05(月) 21:36:11
.NETよりはマシ。
.NETで納入してこようもんなら
即つっかえしだよねｗ
いや
漏れ的には MFC < .NET
結局、VCL/Win32最強、かつ、VCLドトネト使えばドトネトコンパイル。
351 ：
デフォルトの名無しさん：2005/12/06(火) 11:37:16
WXとかFOXみたいなフリーライブラリの商用ソフトって結構浸透してるの？
当方、趣味グラマなんで、その辺かなり興味ありです。
フリーライブラリの商用ソフト？
プログラムする側からしたら .NET > MFC だが
受け取る側からしたら Native > .NET な場合が結構多い。
354 ：
デフォルトの名無しさん：2005/12/09(金) 17:58:23
客先から .NET 環境でなんて指定されたことは一度もない。
ソースも提出しなければいけない客だとほぼ、MFCを言われる。
まぁ、使う側からすれば同じ結果を得れるプログラムがあったら
遅い方をえらぶメリットはないからな
355 ：
デフォルトの名無しさん：2005/12/09(金) 19:19:05
通常、常駐させるようなアプリ例えばウィルス対策アプリなどを
.NETで書いたら絶対売れないｗ
>>344 バイナリエディタでクラス名見たりすればすぐわかるだろ。
そんな場合は、ＭＦＣなんて使わずにWin32だろ
大半のアプリをVB6アイコン丸出しで出荷しても平気（しかもパッケージ製品）というレベルの
職場からすると、「おっMFC使ってる。すごいね～」とか本気で思ってしまう。
>>358 でも真の勝ち組なのは君たちVB組の方。客・受け手問わず。いろんな意味で。断言する。
>>357 「Win32 API」の事を「Win32」と呼ぶのは
君くらいのものです。
デバイスコンテキストハンドルに対して、
「誰が出歯やねん」とつっこむのは
さんまくらいのものです。
花紀京に対して、
「誰がカバやねん」とつっこむのは
原哲男くらいのものです。
全レス読んだけど、結局ここの住人はMFCの何が嫌なのかさっぱりわからん。
俺は便利だと思うけどなぁ。
あと何年持つかな？MFC
>>366 >バグ、異次元仕様、設計者の為の設計
多かれ少なかれどんなものにでもあると思うんだけどなぁ。
俺はそういうもんだと割り切って使ってるし。
371 ：
初心者：2006/03/22(水) 19:09:24
VCLってBCBのクラスライブラリのことですか?
そうだよ
373 ：
デフォルトの名無しさん：2006/03/23(木) 00:31:38
MFCってCでやる
「構造体+関数ポインタテーブルによるオブジェクト指向」
の関数ポインタテーブルを見えなくしただけ、って気がしてきた。こう思うと楽だ
でもWin32APIのハンドルで隠れてる部分がわからん。Win32勉強しなきゃ・・・
今時意味不明なMFCに束縛されてる奴なんてただのチンカスですよ。
要領いい奴はQtで明瞭簡潔に終わらすよ。
チンカスが何かほざいているようです。
デメリットを挙げて「使う理由がない」というならまだしも
「意味不明」というのは、単に理解できていないだけだろう。
まあ、このｺﾃは元々そういう奴だからな。
MFCに必死になってる奴って頭悪そうだな。
一生底辺でしょうね。
Qtがｷﾓｰｲって言われたからといってMFCに八つ当たりしないでください。
379 ：
デフォルトの名無しさん：2006/04/11(火) 17:09:20
MFCってサポート停止決定でしたっけ？
380 ：
デフォルトの名無しさん：2006/04/11(火) 18:45:22
OWLってまだつかえる？つうか、まだ手にはいる？
381 ：
デフォルトの名無しさん：2006/04/11(火) 18:57:54
OWLは手に入るお。
>>381 ｱﾘｶﾞﾄ
それと何処で?見つかんないよ。
ウワ～ンヽ(｀Д´)ﾉ
385 ：
382：2006/04/11(火) 21:52:31
ありがとん。
386 ：
デフォルトの名無しさん：2006/05/01(月) 18:22:13
ダイアログを１個単位でライブラリ化する方法を教えて下さい。
コモンダイアログを参考に
388 ：
デフォルトの名無しさん：2006/05/02(火) 10:34:04
ダイアログ１個をライブラリ化できないようなクソライブラリを何で使うの？
>>388 意味不明。
「ダイアログ１個をライブラリ化できない」のは
>>386 の資質に因るもの。
390 ：
デフォルトの名無しさん：2006/05/02(火) 11:16:05
>>389 ダイアログが、１プロジェクトのrcファイルに全部入って、
他プロジェクトで使えないんですが、
どうしたら良いんですか？
とにかく回答下さい！！！！！
男なら、MFCなんて軟弱なもの使わないで、
Cのみでwinmainから書けよ！
392 ：
デフォルトの名無しさん：2006/05/02(火) 11:48:20
comdlg32.dllみたいなdllにすればできるだろ
ウイザードでMFC dll だ
394 ：
デフォルトの名無しさん：2006/05/02(火) 13:02:39
>>393 そんなバカな作り方があるか！！！！！
普通に作れて、さらに、ライブラリ化が出来るからソフトウェアだろ。
ＤＬＬ一杯作って苦労するんかよ、ドアホ
お前の言う普通ってなんだ？
例えばどういうライブラリを言ってる？
396 ：
デフォルトの名無しさん：2006/05/02(火) 13:14:56
普通に開発できて、かつ、作ったダイアログを他のプロジェクトで使える、
という、物凄く超普通にやること。
それが、ＭＦＣで普通に作るとプロジェクトのrcファイルに全ダイアログ入るから、ﾗｲﾌﾞﾗﾘ化できない。
ちょー＾－０－－－ゴミＭＦＣ
>>392 それが男の生き様ってぇやつさ。
>>390 先ず、質問しようとしているｽﾚがそういうｽﾚかどうか判断しろ。
次に、検索の仕方くらい身に付けろ。
[MFC リソースファイル 分割]
398 ：
デフォルトの名無しさん：2006/05/02(火) 13:34:27
リソース分割できたところでresource.hに連番振ってるの何ともならない。
やっぱゴミーーーーーーーーーーーーーーーーーーー
MFC使わないでSDKのみだって普通につくれば同じ
リソースは何も違わないけど
400 ：
デフォルトの名無しさん：2006/05/02(火) 13:43:36
>>399 ウソ付けーーーーーーーーーーーーーーーーーーーーー
VC++のリソースエディタがリソースファイル管理するだろうが。
お前の言ってる普通の意味がよくわからんから
MFC以外でその普通のやりかたを解説してるサイトを出せ。
普通のやりかたなんだからすぐ簡単に見つかるよな
>>398 無知が恥の上塗りか。
リソースのインスタンスを別にするなら
ID は重複していても構わない。
404 ：
デフォルトの名無しさん：2006/05/02(火) 14:28:44
>>402 じゃあなんで、CDialogを派生したクラスが、フリーのライブラリとしてネットととかに溢れてないわけ？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？
405 ：
デフォルトの名無しさん：2006/05/02(火) 14:34:26
>>403 IDを振る事自体がＯＯＰから外れてるということが分からないの？
IDを振る事自体がＯＯＰから外れてるということが分からないの？
IDを振る事自体がＯＯＰから外れてるということが分からないの？
IDを振る事自体がＯＯＰから外れてるということが分からないの？
IDを振る事自体がＯＯＰから外れてるということが分からないの？
IDを振る事自体がＯＯＰから外れてるということが分からないの？
IDを振る事自体がＯＯＰから外れてるということが分からないの？
IDを振る事自体がＯＯＰから外れてるということが分からないの？
resource.hはresource1.hとか2.hとか量産するの？
普通はコピペするからわざわざライブラリ化なんかしない
407 ：
デフォルトの名無しさん：2006/05/02(火) 14:36:54
× 普通はコピペするからわざわざライブラリ化なんかしない
○ ＭＦＣではライブラリ化できない
408 ：
デフォルトの名無しさん：2006/05/02(火) 14:45:39
コピペ開発に対するアンチテーゼとかアウフヘーベンからクラスライブラリが出てきたんじゃないの？
コピペ開発に対するアンチテーゼとかアウフヘーベンからクラスライブラリが出てきたんじゃないの？
コピペ開発に対するアンチテーゼとかアウフヘーベンからクラスライブラリが出てきたんじゃないの？
コピペ開発に対するアンチテーゼとかアウフヘーベンからクラスライブラリが出てきたんじゃないの？
コピペ開発に対するアンチテーゼとかアウフヘーベンからクラスライブラリが出てきたんじゃないの？
ＭＦＣが出てきた当初から手間が減らないという不思議なライブラリでありながら、
ＳＤＫな人たちが「今までだってそうだったでしょ」と疑問を持たなかったという経緯もある。
だからお前の言う普通のやり方を解説してるサイトを早く出せ
お前の妄想なんか聞いたってしょうがない。
現実に存在するものを出せ
410 ：
デフォルトの名無しさん：2006/05/02(火) 15:06:52
409=ＭＦＣでダイアログをライブラリに出来ると妄想してたゴミ
409=ＭＦＣでダイアログをライブラリに出来ると妄想してたゴミ
409=ＭＦＣでダイアログをライブラリに出来ると妄想してたゴミ
409=ＭＦＣでダイアログをライブラリに出来ると妄想してたゴミ
409=ＭＦＣでダイアログをライブラリに出来ると妄想してたゴミ
>>405 >>398 が誤りなのは同意して頂けたようで何より。
ところで、問題なのは「リソースインスタンス単位で一意でなければならない」という
制約であり、それと OOP との間に何の関係が？
つか、必死に見えるんでそーゆー書き方やめとけ。
412 ：
411：2006/05/02(火) 15:13:36
>「リソースインスタンス単位で
いかん、主語が抜けている…
「ダイアログIDは、リソースインスタンス単位で
に訂正。
>>411 405の最後の１行解決してないよ。バカじゃないの？
405の最後の１行解決してないよ。バカじゃないの？
405の最後の１行解決してないよ。バカじゃないの？
405の最後の１行解決してないよ。バカじゃないの？
405の最後の１行解決してないよ。バカじゃないの？
414 ：
デフォルトの名無しさん：2006/05/02(火) 15:14:52
>>412 バカな内容に訂正は要らないよ。
バカな内容に訂正は要らないよ。
バカな内容に訂正は要らないよ。
バカな内容に訂正は要らないよ。
バカな内容に訂正は要らないよ。
415 ：
デフォルトの名無しさん：2006/05/02(火) 15:16:48
>>411 ＞ところで、問題なのは「リソースインスタンス単位で一意でなければならない」という 制約であり
ＩＤＥが勝手にヘッダーに連番振るからﾗｲﾌﾞﾗﾘ化し難いんだろ。
>>413 ライブラリ化する場合、プロジェクトは別になる。
ということは、ライブラリ側の resource.h がどうなっていようと
そのライブラリの使用者に何の影響もない。
そんなことも解らないのか。頭悪いなあ。
で、OOP は何の関係が？
417 ：
デフォルトの名無しさん：2006/05/02(火) 15:38:48
>>416 もしかしてそのライブラリってDLLのこと？
前提全然理解してないじゃん。頭悪いな。
・ダイアログ１つ１つをDLLにすると開発効率悪杉
・DLLは派生出来ないのでOOPにならない
>>417 >もしかしてそのライブラリってDLLのこと？
いや、DLL に限定した覚えはない。
>・DLLは派生出来ないので
誤り。
419 ：
デフォルトの名無しさん：2006/05/02(火) 16:03:03
>>418 それって、IDEでペタペタコントロールを貼りながら、ダイアログ単位にリソースファイルを分けれるってこと？
420 ：
デフォルトの名無しさん：2006/05/02(火) 21:08:41
DLLにせず、"*.lib"、"*.rc"を使う限り、MFC(VC)では無理な気が…。
他のBCBとか.NETとかは使ったことないんでよく分かんないんですが。
ところで、ちょっと気になったんですが、MFCの場合、動的コントロールって
どうやって実現するんでしょうか？
以前の勤務先の先輩が、そういうMFCライブラリ(動的にボタン等を配置)を作った経験が
あるという話をされてて、その時、私はVB6だったので気にも止めてなかったんですが、
今となっては結構謎です。
動的に配置ぐらいできる
コントロールはウィンドウだから移動や表示、非表示は自由にできる。
あとリソース使わないでコードでコントロールを動的に表示することも可能。
423 ：
420：2006/05/02(火) 21:37:50
>>421 >>422 MoveWindow、ShowWindowは使ったことあるんですが、
"リソース使わないで…"が分かりませんでした。
キーワードを教えて頂けないでしょうか？
CreateWindow
MFCの場合は CButton::Create とか
426 ：
423：2006/05/02(火) 22:33:21
>>424 >>425 ありがとうございます。試してみたらできました。フォントが妙に大きく表示されるのは、OnPaintをいじってないからかもしれませんが…。
CXXXDlg::OnInitDialog()
{
CDialog::OnInitDialog
m_pEdit = new CEdit;
CRect rc(10, 10, 110, 33);
m_pEdit->Create(WS_CHILD | WS_VISIBLE | WS_TABSTOP | ES_AUTOHSCROLL | WS_BORDER, rc, this, NULL);
return TRUE;
}
void CXXXDlg::OnDestroy()
{
CDialog::OnDestroy();
m_pEdit->DestroyWindow();
delete m_pEdit;
}
>>420 BCBは、１つのフォームが、Form1.h/.cpp/.dfmになっててプロジェクト情報とは完全独立。
さらにフォームの派生の派生もIDEで出来る。
イベントハンドラ内で上位イベントハンドラコールまでIDEがメンドウ見てくれる。
428 ：
426：2006/05/03(水) 11:47:35
>>427 BCBいいですねぇ。どこかで、OWLの流れを汲むVCLのオブジェクト指向は
完全なオブジェクト指向で、MFCはWin32APIラッパとしてのためだけの
オブジェクト指向だと聞いたことがあります。BorlandのIDE事業売却は残念ですが…。
MSもMFCを見捨ててWinForms(C++/CLI)なんて.NET依存のものを作らずに、
ネイティブで真のオブジェクト指向のクラスライブラリ・IDEを作って欲しいですね。
問題は何を持って「真のオブジェクト指向」と見做すかと言うことだ。
>真のオブジェクト指向
こんなもの追求するなら、
クラスベースという中途半端なもの捨てるしかないっしょ。
誰もそんなもの望んでない。
>>419 それで419にとっての疑問は解決したのかな？
俺は日曜プログラマーで無茶苦茶にシロウトくさい人間だ。
そんなヘタレにとってDialogの使いまわしは非常に重要だったのでやり方を覚えた。
（カスみたいなチッポケなプログラムなのでその程度でも大変に思えるということなんですがね）
ヘタレの俺のやり方を書いてみる（貧乏臭くVC6ですヨ）
新しくプロジェクトを作った後、［ファイルを開く］で使いたいダイアログの入っているプロジェクトの
フォルダに行って***.rcをクリック、explore風の表示でDialogフォルダを開けて欲しいダイアログを
新しいプロジェクトのリソースに、まんまドラッグする。（ここで移動じゃなくコピーするを択ぶ）
ListViewとかではICONも必要なので同じようにドラッグでコピーする。
これだけでOK
あとはダイアログのクラスとか勝手に作りたがるので可能なら同じ名前で作ってしまう。
そして、今度はそのコピったダイアログクラスの*.h,*.cppの中味をザックリ入れてOK
ダイアログクラスそのものに実装は終わり。
あとは好きに料理する。
ま、これは俺と同じで日曜プログラマ用なんだろうがこれを見出すのに俺は時間が掛かったｗ
ので役に立つかもと書いてみた。
432 ：
デフォルトの名無しさん：2006/05/03(水) 22:17:15
>>431 それってコピペコーディングであって、
ライブラリでも何でもねーじゃん、ダッせー。
＞あとは好きに料理する。
あほか。
>>432 431はライブラリとは書いてない。
自分の振った話題しか見えないのはキミが低脳だからなのが解るか？
またダサくない方法も提示できないのであれば、低脳な上にカスでもあるｗ
わかったかいカス
>431はライブラリとは書いてない。
言語～開発環境で、ライブラリ化出来ないものに存在意義あるの？
435 ：
428：2006/05/03(水) 23:50:50
コードの全てはライブラリであるべきだと？
ちょっと読み間違い。誤解を生む文章だったかも。
ソフトウェアの開発ツールでありながらライブラリ化を上手くできないのは如何なものかと、
といいたいだけ。
ライブラリ化に関しては
>>427-428 みたいなものもあるし、
Ｃ丼もそういうつくりになってるらしいし。
リソース関係は容量食うからDLLが一般的なだけで
スタティックリンクやろうと思えばできそうな気もするな
同じリソースを全部のEXEに持たせるのはアホらしいから
馬鹿以外はそうしないだけなのかも
試してからできないと言ってるんだろうか？
rcをインクルードしたらできた
ということで
>1-439はアホ
で、
>>427-428 をMFCでやろうとしたらどうすれば良いの？
VC++のIDEでポトペタしながら。
コピペのやり方ならでてたじゃん
リソース開いてドラッグドロップ
コピーじゃだめ。
ソース共有したいんだから。
だって片一方のプロジェクトで拡張しても、もう片一方が古いままじゃん。
ソース共有はソフトウェアの基本！
444 ：
デフォルトの名無しさん：2006/05/04(木) 13:33:58
#incllude すりゃいいじゃん
>>444 おまい、MFCがresource.hを固定で持ってることや、
rcファイルに全ダイアログリソース持ってること知らんだろ。
MFCじゃなくてVC++のIDEでダイアログ作ると、
resource.hが固定だったりrcファイルが１つに固定だったりするのがガンなんだな。
これが
>>427-428のようになれば便利なんだが。
VCのリソースはrcファイルに無くても書けるんだな。
ソースファイルに。
これは、MFC以前の話だな。
>>443 もう一方が古いままｗ
あたりめーじゃねーか、完成したものにリソース改変の副作用を与えてどうする？
てかスゲー馬鹿だろオマエ
>>447 つ
>>446 >>448 おまえは本当に馬鹿なやつだな。
そうくると思ったが、CVSでバージョン管理してるから問題無いし、
ソース共有出来ない理由が「副作用」だなんて、キチガイの中のキチガイ。
共有できない世界ってのはソフトウェアの特性が無いってこと！
それハードウェア。
450 ：
デフォルトの名無しさん：2006/05/04(木) 13:51:14
もう一つ書いとくと、
>あたりめーじゃねーか、完成したものにリソース改変の副作用を与えてどうする？
副作用にすべきじゃない部分をベースクラス、
そのプロジェクトの固有部分を派生クラスにすんじゃね？
BCBなら完璧にそれできるぜ。
変なレスがきそうなんで書いとくが、
BCBではフォームに関して、
副作用にすべきじゃない部分をベースクラス、
そのプロジェクトの固有部分を派生クラスに出来る。
CDialogに関してコピペしか手が無いのが、VC++IDE/MFC。
何をどう言い訳しようが、
クラスライブラリである限り大前提の特性がある。
基本部分が既にあって差分を記述するだけで開発出来る。
コピペが必要なクラスライブラリは飛んでもキティのカタワライブラリ。
MFC使いは頭がカタワ。
454 ：
デフォルトの名無しさん：2006/05/04(木) 14:01:13
WTLってポトペタした画面を別プロジェクトで使ったり、
さらにそれにポトペタできるんだっけ？
そういう考えならアイコンも継承しないとだめだな
455=頭がカタワ
ｵﾏ、もう不要。
別にレスしなくて良いから。
C++じゃないリソースを継承しろっていわれてもな
リソースを継承しろと逝ってるんじゃない。
i) IDEでCDialogにポトペタしたCMyDialogを他プロジェクトで使えるようにしろってこと。
ii) さらに別プロジェクトでCMySpecialDialogに継承出来たら理想だなってだけ。
で、おなじ事をBCBなら何も考えなく出来る。
フォーム単位でファイルが分かれてるからプロジェクトに組み込むだけ。
アイコンは.iconファイル、ツールバーならbitmapファイルでフォルダーに存在するよ。
まんまコピペできる。
.rcファイルではパスを通してやってるだけ
or
stringテーブルで名前にパスを通してやってるだけ
そうか、普通に出来ることをMFCで出来ないから、
MFCばっか使ってる人には何の話か皆目検討もつかないって事か。
こういうのを不自由とかカタワという。
それでアイコンを継承しる！とかイミフメなレスが出てくるんだ。
フォーム単位でわけて別ファイルに保存
使いたいやつをinclude
>>461 >フォーム単位でわけて別ファイルに保存
これが、VC++のIDEでポトペタするときに不可能だから困ってんだな。
MFCを廃止した方が世の中幸せになりそうだな。
M$が社内ではMFCを使ってないように。
大体、M$はC++を流行らせないことによりオプソに対抗したわけだが、
MFCみたくキチャナイもので開発者からC++から遠ざけﾌﾞﾋﾞ厨を大漁生産した。
コピーしていらないやつ消せばいいだけ
IDEでダイアログ単位で別ファイルに保存
これは可能
CDialogクラス(だけ)は独自にClassを作れるよ。
CDialogはC～AppクラスがRuntimeとは別枠で作ってるから、Doc-Viewアーキテクチャ、基い、
Runtime、のカセから逃れられる。
>>466 resource.hとかダイアログ単位に別ファイルに可能？
rcファイルをダイアログ単位に別ファイルに可能？
その操作を書いてるサイトきぼん。
それが出来るならその通り使うから。
>>463 > M$が社内ではMFCを使ってないように。
というのは違うかもしれません。VC++6.0のIDE自体はMFCで開発されています。
(少なくともSpy++、DelendencyWalkerで確認した限りでは…)
458 にあることの実現は、現状のMFC(WTL含む)では不可能ですが、C++/CLI等で
WinFormsを使用すれば、リソースファイル(*.resx)が各フォーム毎に生成されるので
多分実現できるのじゃないかと思います。
#include
>>469 古いアプリにはMFC使ってるだろうが、MFCじゃなくて別のクラスライブラリを使ってるっていう記事見たお。
ﾄﾞﾄﾈﾄはやなんだよ。というか、使う予定０。
>>472 VC6だと、
表示＞インクルードファイルの設定＞コンパイル時に追加するファイル
だね
474 ：
469：2006/05/04(木) 15:05:24
>>471 > 古いアプリには…
そのとおりです。VS2003のIDEでは、MFCを使わず、Officeと同様のGUI部品を使っているようですし、
加えて、VS2005のIDEでは、.NETランタイム依存となっています。
> ﾄﾞﾄﾈﾄは…
まぁ、それは正直、私も同感です。M$がC++/CLIを強引にISO化したところで、
私はあれをC++の進化系と認めたくはありませんし、使いたくもありません。
>>472,473
"#inlude"ってなんのことだと思ってたら…orz。失礼いたしました。
>>449 > CVSでバージョン管理してるから問題無いし
使用経験ゼロのヤツ
> 共有できない世界ってのはソフトウェアの特性が無いってこと！
> それハードウェア。
ハードウェアがカスタムだと思い込むシロウト（PGAとかあるにはあるがナ）
オマエ勉強しなおせよ何もかも
476 ：
デフォルトの名無しさん：2006/05/05(金) 22:15:16
うわ、 475新生キティだわ。こりゃすげ。
>> CVSでバージョン管理してるから問題無いし
>使用経験ゼロのヤツ
ちょ、、、、日本語でおｋｗｗｗ
CVSでバージョン管理して
>>450 のように開発していくことを教えてあげてるからね。
>ハードウェアがカスタムだと思い込むシロウト（PGAとかあるにはあるがナ）
ちょ、、、、知ったかやめれ。FPGAだがや。
それからハードウェアというのは「独自基板」でカスタム。
それに財リンクスとか組み込んでFPGAするわけ。
で、FPGAは「ソフトウェア」だから。
論理的思考も出来ないようで、存在価値のないやつ乙！
478 ：
デフォルトの名無しさん：2006/05/06(土) 01:34:25
>CVSでバージョン管理して
>>450 のように開発していくことを教えてあげてるからね。
日本語でおｋ
>それからハードウェアというのは「独自基板」でカスタム。
日本語でおｋ
>論理的思考も出来ないようで、存在価値のないやつ乙！
日本語でおｋ
>>476 PGAで通じるんだよ。
ＦＰＧＡには色々なタイプがある、WriteOnceなものは配線を切るものもあるんだ
Ｘｉｌｉｎｘのようなものは低速だというやつも居る。
ボードを触った経験ぐらいしかないカスはダマットレ
あとさ、高々ダイアログ程度をライブラリなどどホザク低脳がカスタムでハードとかってのは失笑するしかないな
オマエバカな学生だろ？それも実際には何もやったことのない
PGAっつーとパッケージのほうを思い出すな。
ゴルフツアーでもいいがｗ
480の文って１行1行繋がりが無いのは何で？それも全行。
スレの流れに沿ってないどころじゃなくて中身が存在して無い。
統●失調？
480の学生時代はバカで
何もやってなかったってことだろうか。
また初段から落ちた…
485 ：
デフォルトの名無しさん：2006/06/01(木) 21:28:39
最初は「なんだこりゃ？」だったけどCOMとかオートメーションとかActiveXの勉強してみると
「またむりやりC++でくっつけたなぁMSは。でも、仕方ないか」と思えるようになってきたところ
勉強始めたところだから間違ってるかもしれないし、MFCというよりもVisualStudioがすごいのかも知れないけどね
どうもATLとかWTLを使えばもっと強力なのかもしれないけどそれは次に置いておいて
MFCで勉強をすすめるかな
>>485 勉強するならWTLを激しくお勧め。
きれいなソースで継承関係でもっさり感が80%減（MS社比）
VC++が出力する気味の悪いテンプレートに悩まされず、VCのバグに
巻き込まれにくい。
問題はドキュメントの数と認知度の低さ。趣味グラマーならWTL。
つーかMFCに勉強する所なんて無い。バッドノウハウの温床だよ。
WTLはVS2005 EEで使えないんじゃなかったっけ
>>487 使えない？（´・ω・｀）
最悪make環境でも作れるぽ。効率悪いけどｌ。
意外とフレームワーク等を自作して使っている人って少ない？
490 ：
デフォルトの名無しさん：2006/06/02(金) 00:48:50
Expressでも使えるようにできる
つーかMFCこそ使えないし
MFCのソースコードはもうAPIのサンプル集と思ったほうがいい
あれがオブジェクト指向だと信じられていた時代があった・・・
>>486>>489 WTLはATL抜きで使えないから俺も自作した。
ATL（の少なくともWTLに必要な部分）が自由に使えるのであれば、
文句無くWTLを使うんだけど。
>>492 Expressで使えるぞ
ATL3だがWTLはちゃんとサポートしてる
Express+WTLはExpressの存在理由だろう
>>493 Visual C++以外でもWTLを使いたいの。
MFCは、クソマクロや定数がちりばめられなければ
まだ使おうという気にもなるんだが・・・。
VBerにも使えるMFCには存在価値がある
497 ：
デフォルトの名無しさん：2006/06/05(月) 08:38:13
>>496 断言するけど使えない。
C++を１０倍難しいものにするＭＦＣ。
MFCだとメッセージ処理、WinAPIまでつっこまない(=時間の浪費)と
まともにプログラムできない。
それと国際化対応、スレッド、コンテナの直行性、モダンでないシリアル化がいまいち。
互換性が完全に足枷になってるんだな。(VC7.1Userです。VC8ってなんか変わったの?)
.NETはSTL.NETがまだ使えないので洗練されたコンテナが...
499 ：
デフォルトの名無しさん：2006/06/05(月) 18:15:43
つまりVCL最強って琴田
いっそQTとか
501 ：
デフォルトの名無しさん：2006/06/10(土) 07:03:23
MFCつかうと一気に実行ファイルサイズが10倍に?！
502 ：
デフォルトの名無しさん：2006/06/10(土) 11:08:26
みんな！！MFCの悪口を言うなよ！
MFCも、今にきちんとするつもりなんだよ、きっと。
>>502 きちんとしようとした VB が VB.NET になったように
過去の互換性を捨てて MFC on .NET に！
…わりぃ、要らんわ。
Win32のラッパだからWin32があるかぎりMFCも使える。
Win32がなくなればMFCも不用
＞過去の互換性を捨てて MFC on .NET に！
過去の互換性があるMFC on .NETも炒りませんが、何か？
507 ：
デフォルトの名無しさん：2006/06/12(月) 20:54:47
∧,,∧
(；`・ω・） MFC on .NET
/ ｏ━ヽニニニニニニフ))
しー-Ｊ
. n T
o E
F N ／|
M C ／／
／／
∧,,∧ ／／ ｜
(；`・ω・）ｏ ￣ ｜
/ ／ ｜
しー-Ｊ
ウリャァ～
| | |
∧,,∧
(；`・ω・） noT MEN FC.
/ ｏ━ヽニニニニニニフ))
510 ：
デフォルトの名無しさん：2006/09/06(水) 16:09:14
VC++使ってますが、デバッグのトレースで、
STRCORE.CPPの240行目CString::CString(LPCTSTR lpsz)の中まで入ってしまいます。
入らない方法教えて下さい。
引数にCStringが有った場合、
ステップオーバー →メソッド通り越し
ステップイン →上記
で、困ってまつ。
511 ：
デフォルトの名無しさん：2006/09/06(水) 16:26:39
MFCに嫌気が差したのなら使わないほうがいいよ。
＞C++の効率的な勉強方法
＞
ttp://pc8.2ch.net/test/read.cgi/tech/1147352337/ 240 名前： デフォルトの名無しさん [sage] 投稿日： 2006/08/21(月) 22:56:44
ﾉｼ
(Turbo)C++からいきなりはいったくちです。
Cは本（初めてのCだったけなぁ）読んで流した程度。
borland系のGUIクラスライブラリはOO的に綺麗な設計
でそれを解析しながら仮想関数とか勉強したっけ。
MFCを先にやってたらと思うと背筋が寒くなる。
これは痛いな。
俺と全く同じなんだが、そんなに痛いのか。
漏れも Turbo C++ で OWL 使いまくってた
あれのおかげで OOP 理解出来たし
MFC の糞さも使う前から分かったので未だに使ってない
Win32API + 自前クラスライブラリでウフフ
>>515 >MFC の糞さも使う前から分かったので未だに使ってない
なんだかなぁ。
>Win32API + 自前クラスライブラリでウフフ
MFCより良ければいくらか商売になるよ。
>漏れも Turbo C++
名前で混乱させられるね。
>MFC の糞さも使う前から分かったので未だに使ってない
ウィザードでソースコードジェネレートした時点できちゃな杉だよね。
画面の着色に関してはペンとか生成してWin32と変わらないどころか、
見通し悪いくらい。
何にせよ、MFCのメジャーバージョンうｐが停止されて、
他環境に広がらなくて良かった。
なんかの本でMSKKの奴が必死に弁解してたな。
「MFCはあれでよかったんだ！！汚いのはねらってやってたんだ！！」って
519 ：
デフォルトの名無しさん：2006/09/16(土) 23:42:12
あんなにCみたいなキャストさせるのはヤメテ・・・
まぁこれはWin32APIの段階からキャストは必要だといわれればそうだけど
CString Str1, Str2, Str3;
として、
Str1 = Str2 + Str3;
って書けたっけ？
strcat等のstr系でしか書けなかったっけ？
書けるけど、漏れは Str1 += Str2; Str1 += Str3; と書く。
MFC便利！！
APIガリガリうざい。
MFC苦汁の選択！！
APIガリガリが上手くラップされてないのがＭＦＣ
うまくラップされているものはあるのか？
なにいってんだVCLにきまってんだろぼけ
お決まりの回答だ。つまらん
VCLは良いんだけど、フリーで組み込みに使えてポトペタできるライブラリきぼん。
作れたら何でもいいじゃん。
MFCもVCLも、過去の遺産だろ？
VCLは過去からの遺産だけど今も使える。
というか、VCLの代わりが無くて困ってる。
>>482 いや、キミに読めないというだけのこと。
480の内容は板違いネタだが普通に読める。
そうは言っても480のレスなど理解する必要も無いような内容だがな
482の無知はここの板であれば罪ではない範囲
「自分に理解できない内容＝統合失調」って短絡は失笑ものではあるが
ｗｘＷｉｄｇｅｔｓに移ろうよ。
今酷い自演を見た
535 ：
デフォルトの名無しさん：2006/10/15(日) 16:51:28
FOXに移ろう
536 ：
デフォルトの名無しさん：2006/10/27(金) 04:45:24
つATL/WTL
PGやめようよ
PG(笑)
どうした？
PGがそんなに面白かったか？
反応したw
どうした？
反応がそんなに面白かったか？
かわいそうｗ
どうした？
かわいそうなのがそんなに面白かったか？
↑
おまいも用地
入れ食いw
547 ：
デフォルトの名無しさん：2006/11/08(水) 13:31:59
なんだ尺八郎か
>>547 一貫性が無いって言うのは、確かにうなずけるな
最悪では無いと思うけど
>>549 最悪じゃないってことは、何よりマシってことよ？
551 ：
デフォルトの名無しさん：2006/11/14(火) 00:02:47
だが、くそもっさりした.NETよりはぜんぜんよくないか？
C#は結局C++に挫折した奴が書くスクリプト言語でしょ
もっさりで、.NET Frameworkが必要なことに目をつぶることができるなら、
MFCより.NET Frameworkのクラスライブラリは大分まし。
世の中にはドトネトじゃないまともなクラスライブラリがあるわけだから、
Ｍ＄のダサダサ開発環境捨てるべきじゃね？
ネイティブ、ＣＯＭ、ドトネトの三つ巴の関係を考慮しながら開発なんて超変だお。
>>551 >C#は結局C++に挫折した奴が書くスクリプト言語でしょ
いや、実行時にコンパイルされるCモドキのVB。
じゃ、ドトネトは巨大なＶＢランタイムか。
C++に挫折するやつはC#も書けない気がするけどなｗ
>>555 VBのランタイムライブラリは
予めコンパイルされているだけ、まだまし。
.NET Frameworkのクラスライブラリはインストール時にngenをかけていると聞いたことがある。
使えればなんでもいいじゃん。
中の実装なんて、どうでもいいじゃん。
いやなら、VCL（古臭い）でも使ってろよ。
561 ：
デフォルトの名無しさん：2006/11/16(木) 22:52:48
↑
使いにくさですよね？
563 ：
デフォルトの名無しさん：2006/11/17(金) 20:44:36
566 ：
デフォルトの名無しさん：2006/11/17(金) 22:12:13
MFCが汚いなんていってる人って結局C++が理解できていないんだよね
>>566 あの酷いコレクションクラス設計からしてマトモなAPIじゃないよ。
Doc-Viewアーキのカセ、むしろ更に、APPとFrameとDocとViewにはめられているRUNTIMEの鎖が汎用性にはネックになる部分で
慣れれば、用途によりけり抜け道と言うか、持って行き方があるけど。
自動生成のソースを全て底のクラスの意味まで理解すれば、色々応用が使えるようになってくる。
確かに特にRUNTIMEはマクロ、テンプレ、仮想関数(実行時まで型を決めずにおける)満載で、ウィンドウ用途に限って言うと、C++を存分に使い切っている。
マルチウィンドウ、例えば、ブラウザではサイトによりFormは無限だが、同様にTreeViewで開いたモノにより、画面を変えるなんてのにはMFCは最強。
.NETは使ったことは無いから分からないが、ActiveXはコンポーネントの中身が見えないのと同様のものを感ずるが、MFCはソースとしてフルに見れる、確かに大量にはあるが、元を辿るぶんには結構な量ではあるが、半端無いわけじゃない。
そして、ちまたにあるできあがったコントロールを使うなら、非常に楽にできる、できるようになるまでがたいへんだけど。
が、クライアント用途以外を考えるなら、WINDOWS以外も考えなければならないのでMFCじゃ無理。
569 ：
デフォルトの名無しさん：2006/11/17(金) 23:46:44
Doc-Viewがカセ？
ポトペタ環境がありがたいと感じるのは最初だけ。
C#やVBはポトペタ環境がﾏｼﾞうぜー
My Favorite Class-library
>>569 例えば、
ファイルダイアログ＞開く・保存なんてのは、MFCじゃほんの数行でできるが(注:カセに則ってる分には)、
ファイルダイアログを開かずに直接、DATなりから自分が独自に作ったクラスにserialize使うなり、archive実装するとなると、最初はつまづくでしょ。
MFCの場合は、最初に壁があって、そこを超えると使いやすさが広大に開ける、そんなのが多い。
MFCの文句をいうならMFCで出来たものを使うなよ～～～～～～
573 ：
デフォルトの名無しさん：2006/11/18(土) 02:27:18
.NETもReflectorでざっと読んでみたが糞設計だな・・・
Doc/Viewなんて、STLでDoc実装＋Ｖｉｅｗの描画にポトペタ部品の派生が最強。
結論：ポトペタ部品の派生が簡単なＶＣＬ最強。（ＤｅｌじゃなくてＢＣＢ）
ＭＦＣがOOPになってないところ羅列
・描画中にCBrushとか自分で生成破棄する必要がある。
それはOOPとは関係ないだろ
ウィンドウが自分を描画するブラシぐらい持つべきだろ。
持ってないならクラスにならん。
ＭＦＣがOOPになってないところ羅列
・ダイアログのリソースが１ファイルに収まるため、別プロジェクトがダイアログクラスを普通に共有できない
それはOOPとは関係ないだろ
CDialogクラス派生した部品が他プロジェクトの派生部品となりえない・・・ｱﾘｴﾅｽ
ＭＦＣがOOPになってないところ羅列
・ダイアログに貼る部品がActiveXであって、C++のclass宣言でクラス派生できない
それはOOPとは関係ないだろ
クラス派生できない→OOPではない
584 ：
デフォルトの名無しさん：2006/11/20(月) 10:41:09
MFCはOOPとは関係ないだろ
585 ：
デフォルトの名無しさん：2006/11/23(木) 22:21:16
つか、OOPとMFCは関係ない
はぁ？MFCにはOOPは関係ない
587 ：
デフォルトの名無しさん：2006/11/23(木) 22:52:30
はぁ？OOPにはMFCは関係ない
もうちょっと変化に工夫を付けろ
589 ：
デフォルトの名無しさん：2006/11/23(木) 23:36:15
はぁ？OPMにはCOFは関係ない
はぁ？KFCにはMACは関係ない
麻雀格闘倶楽部かと思った
592 ：
デフォルトの名無しさん：2006/11/26(日) 19:54:07
あそこまで妙なマクロは使ってないけど、自作のC(not C++)のライブラリに似てて鬱だ>>MFC
593 ：
デフォルトの名無しさん：2006/11/28(火) 17:17:55
ここは麻雀格闘スレですよ
594 ：
デフォルトの名無しさん：2006/11/28(火) 22:22:52
そんな貴方にWide Studio
595 ：
デフォルトの名無しさん：2006/12/02(土) 20:25:03
今後、.NETが浸透してネイティブアプリなんて必要なくなるのかな？
アプリケーションの必要性は使用されているライブラリやアーキテクチャには無い。
その有用性にあるのだ。
597 ：
デフォルトの名無しさん：2006/12/03(日) 05:03:07
んなこと言ったらみもふたもない。
道具として何がよいかどうかの話なんでは。
漏れはもう、.NET/C#で事足りるなら、わざわざC++でネイティブアプリ作る気にはならないかも。
んで、実際大抵の用途には事足りる気がする。
ネイティブ実行ファイルが生成出来て
使いやすいC++のRAD開発環境があればいいけどね(M$製で)。
D言語 + RADでネイティブ吐く環境のがもっといいかも(やっぱM$製で)。
VC++とMFCでWinのプログラミングするのはほんと大変。
ある程度まともなアプリ書ける様になるまで3年かかった。
しかし未だ分からない事は山程あるので、まだまだ一人前とは言えないし。
MFCはウインドウのフレームだけでペインの中は自分でバリバリ書いてねってフレームワークだから、
RAD風にコントロールを並べてというのを期待するとCFormViewしかないので戸惑う。
C++ベースでRAD系の開発ツールはサードパーティにまかせて、あえてMSは出さなかったという話を
聞いたことがあるがソースが出てこない。BC++やVisual Age C++がそうだったのだろうか。
602 ：
デフォルトの名無しさん：2006/12/04(月) 00:48:42
RADツールでもお客の要求などからコントロールを１から書くことが結構ある。
RADツールしかつかったことないひとはちょっとした変更でもできないなんていう。
たとえば、グリッドなんかでセルにボタンを配置してくれとか、コンボを配置してくれとか
簡単なのにできませんなんて・・・
そういえばMFCもけっこう使ったけど、CFormViewてほとんど使ったことないかもしれん。
604 ：
デフォルトの名無しさん：2006/12/04(月) 01:06:39
ふつう使わない
Office2007はMFCなんでしょうか？
これからもパッケージソフトはC++でMFCなの？
C#とVBではプログラム作れるようになったけど、VC++でMFCもやっておいた方がいいんだろうか？
などと、学生は考えてしまいます
606 ：
デフォルトの名無しさん：2006/12/04(月) 02:23:11
C#とVBは３日あれば覚えられる
事前にどういう言語知ってるかによるだろ
608 ：
デフォルトの名無しさん：2006/12/04(月) 02:30:22
はぁ？
C/C++をしらない奴みたことないぞ
C#にはC/C++にない概念もあるだろ。
言語だけわかってもでっかいライブラリをある程度把握しないと何も出来きないし。
そういうのは他との対比ができれば理解が速いと思うけど。
VBは知らん。
610 ：
デフォルトの名無しさん：2006/12/04(月) 13:22:21
すまん、VBでもmainから始めてた、偽装派遣で客先いくまで
どうでもいい
MFCかどうかはともかく、当分はC++の独占場だとは思う。
最近までVC6.0がメインで誰もC++を知らないC言語ワールドにいました。
>>613 Cだけ使ってる分にはVC6は軽くていいかもな
MSVCRT.DLLなら普通の環境にはデフォで入ってることが期待できるし
なんだかんだ言ってもいまだにVC6はインストールしてあるｗ
616 ：
デフォルトの名無しさん：2006/12/07(木) 18:04:42
MFCってVC++2005でもサポートされるんだっけ？
MFCのメジャーバージョンうｐとかどうなんでしょ。
VC++ 2005 （Std以上）にはMFC 8が付いている。
618 ：
デフォルトの名無しさん：2006/12/07(木) 18:26:04
＞MFC 8
VC++6のMFCと互換性おｋ？
619 ：
デフォルトの名無しさん：2006/12/15(金) 00:54:53
俺はWEBアプリばかり作ってたから、未だにMFC未体験。
620 ：
デフォルトの名無しさん：2006/12/15(金) 01:36:29
WEBとMFCになんの関係があるの？
どちらかというと、関係がないと言ってるように見えるのだが。
Ｖ＄ドトネトに逝行してもＭＦＣ使ってる人っています？
逝行の致命的な問題とか無いでつか？
623 ：
デフォルトの名無しさん：2006/12/19(火) 11:17:23
＞CDialog１つに対してresource.hとrcファイルがあって、
＞プロジェクトをダイアログ単位の部品クラスに分割できれば、
＞まだ使えたようなｷｶﾞｽﾙ
他のプロジェクトにダイアログをカレントプロジェクトにコピペといった使い方しかできないおね。
ＭＦＣのパワーユーザーとか、他のプロジェクトのダイアログをクラスライブラリとして使いまわせない事をどう思ってんだろ？
コモンダイアログ
＞コモンダイアログ
ＭＦＣではない。
ダイアログテンプレート
Vi$taでもMFC使い続けますか？ドトネトにコンバートしますか？
>>623 ダイアログのリソース関連はまったく同意だなぁ
新しいプロジェクトはDLL化して分割管理しているからまだマシだけど
ずっとメンテナンスしてるプロジェクトがダイアログリソースだけでが２５０くらいあって
もうどうしようも無い感じなってきてる
ダイアログリソースって壊れやすいから嫌い。
変なマクロもぶちまけるし。
ソースとリソースを相互変換するツール作ればいいだけじゃ？
＞ソースとリソースを相互変換するツール作ればいいだけじゃ？
つ BCBなら１ダイアログが３ファイル（.h/.cpp/.dfm）
ダイアログテンプレート
632 ：
デフォルトの名無しさん：2006/12/22(金) 02:38:35
厨な質問だと重々承知しておりますが質問します。
WindowsオンリーであればＭＦＣ使った方がいいですかね？
世間の評価が気になるのですけど、ＭＦＣ？：( ´,_ゝ`)ﾌﾟｯてな感じになりませんか？
>>632 お好きなように。
>ＭＦＣ？：( ´,_ゝ`)ﾌﾟｯてな感じになりませんか？
MFC でも何でも、マトモなものが作れてるなら問題ない。
いや・・・さすがにMFCとSTLを同列で扱ってたりするような糞サイトは参考にならんと思うが・・・
＞MFCとSTL
MFCのCStringとstd::string問題を扱ってるだろ。
635=その問題を知らないとはC++使ってるとは言えない。
パソコンだって箱より中身の方が大事なわけだし
それがわかってれば箱なんか気にしない
>>636 std::stringはSTLじゃないよ。
MFCもSTLもstringもC++のライブラリ。
同列に並べずどうする？
Windowsプログラミングを行うためのライブラリであるMFCと
標準ライブラリを同列に並べるの？libgnomeとlibcぐらい違うでしょ。
MFCのごく一部がC++標準ライブラリと被ってるのは確かだ。
だからMFCのコンテナを使うくらいならSTLのコンテナを使いましょうと言うならまだ分る。
要はMFC全体は標準ライブラリと排他的に選ぶものではないということ。
サイトには、
＞MFC はＣ＋＋のお手本として良い題材とは思いません。STL の勉強をお薦めします。
と書いてあるから、排他してなくて、勉強時にはMFCとSTL比べたらSTLを選べと言ってる。
＞要はMFC全体は標準ライブラリと排他的に選ぶものではないということ。
おまいのいいがかりじゃん。
よく読めよ。MFCを勉強するかSTLを勉強するかではなく、
C++を勉強する時に使うべきはSTLかMFCかとおっしゃってるわけだが。
＞C++を勉強する時に使うべきはSTLかMFC
C++を勉強するときに、STLとMFCと選ぶという行為は変じゃない。
その場合のSTLの選択も正しい。
で？
＞STLとMFCと選ぶという
あ、ゴメンあいまいに書いちゃった。
C++勉強しよう。STLを勉強しようかな、MFCを勉強しようかな、という同列に並べた選択は変じゃない。
ごくふつー。
まぁ、MFC使って、
AppWizardの吐き出したコードの汚さに目が点、
画面に使えるコントロールが少ない、
それでも画面を何とかするにはActiveX使うしかない、
という流れでどうせ頓挫するさ。
という意味では、一旦MFC漬かってみれば結論でるお。
> C++勉強しよう。STLを勉強しようかな、MFCを勉強しようかな
作れるものが全然違うから同列に出来ないと俺は思ってる。
何かを作るのが目的でC++を勉強するってのが俺のスタンスだからだろうけど。
MFCを使ったコンソールアプリを作るのがMFCの勉強とは思えない。
堂々巡りでスレ汚しになる予感だ。
ケチ付けた方からで悪いが、この件はMFCの糞さとは関係ないからここら辺にしておこう。
＞作れるものが全然違うから同列に出来ないと俺は思ってる。
「作るものが～」という文脈は、作るのが目的の場合。
勉強する場合作るものはある程度何でも良くて、C++文法やクラスライブラリ構造の１例理解がターゲットだったりするわけ。
もうObjective-CとCocoaに移行すればいいじゃん。
そうすれば糞面倒なC++とMFCにもおさらば。
C++が面倒（やっぱ、慣れるまではちょっと面倒）なんじゃなくて、MFCが面倒。
それから、C/C++系ライブラリは必要、MFCは必須ではない。
一度でいいから見てみたい。
MFCを使わずにC++とWin32APIで
クラスの概念の存在意義を見いだせる書き方をされたコード。
ATL/WTLはどうですか？
＞MFCを使わずにC++とWin32APIで
C言語とC関数ライブラリでひとかたまりのように、
C++とクラスライブラリで一セット。
分離はできない。
MFCを別のクラスライブラリに差し替えるのが正しい。
小物を沢山作る人なんかは自分で小さいクラスライブラリを作ってる事もあるね。
漏れも昔はやってた。
サードパーティの有料コンポーネント使った方が速いというか
657 ：
デフォルトの名無しさん：2006/12/26(火) 20:37:28
サードパーティの有料コンポーネントってびみょーなのが多い
なんだこの程度のコンポーネントで売り物になるんだと思うことがほとんど。
自作したほうが、早い
wcはcの入門書の例題によく出てくるから、まあ範疇でいいじゃない。
wc sed grep lsなど簡単なunixコマンドは大抵win32版がgnuその他のフリーウェアで
転がっているから、ググレば拾えるよ。
今ってネットにフリーのクラスライブラリのソースそのまんまのコンポーネントが溢れてる時代だよね。
ＭＦＣはマジでその辺が無い。
漏れはCodeProjectでさんざん世話になったが・・・
ほっしゅ
663 ：
本田：2007/01/03(水) 19:07:29
664 ：
デフォルトの名無しさん：2007/01/12(金) 10:24:15
＞永久プログラマー
＞
ttp://www.est.co.jp/ks/billg/09_EPROG.htm マイクロソフトC/C++7.0とクラスライブラリMFC1.0を使って、アプリケーションを作り始めた。
半分ほどプログラミングした時点でVisualC++1.0が米国で出荷された。
その開発環境の良さやMFC2.0の高級な機能に刺激されて、VC++に開発環境を移行した。
MFC1.0は、Win16APIにクラスライブラリの皮を被せただけの簡単なものである。
彼はこの上に、独自の高級なクラス構築していたのだが、MFC2.0が見事にそれを葬ってくれた。
MFC2.0に合わせて、モジュール構造から作り直すのに6ヵ月ほどを費やした。
>>664 ＞久遠のプログラマー
マイクロソフトC/C++7.0はMFCなどの分厚いマニュアルが何冊も付いてきて、
パッケージの幅が５０ｃｍはあったと思う。
これを抱えたまま秋葉原駅の階段で転倒。腕の骨を骨折するに至った。
666 ：
デフォルトの名無しさん：2007/01/14(日) 02:10:59
ワロタ
668 ：
デフォルトの名無しさん：2007/02/09(金) 11:54:29
Vi$taでもMFC使える？
>668
おいしい情報を教えるよ。
僕が開発した、「馬鹿には見えないMFC」を使えば、Vistaでもツルツル動くよ。
格安で譲って上げるから、レスちょうだい。
670 ：
デフォルトの名無しさん：2007/02/09(金) 20:50:33
ツルツルａｇe
671 ：
デフォルトの名無しさん：2007/02/10(土) 10:00:05
メモリーフローコントロール
>>665 VisualC++1.0の紙マニュアル付きを思い出す
あれ買って帰った人いるのかなぁ
あげあげ
MFCに四苦八苦しながらもようやくまともにアプリ書けるようになったと思ったら
.NETにWin64APIですか…orz
>>674 MFCよりゃ癖もなくて楽だと思うけどね。
MFCにかわるものはあるんですか？
（個人的にMFCは嫌いじゃない）
MFCの様にやりたいなら、MFCが一番だろｗ
MFC（GUIイマイチ） + VCL（某製） → .NET（モッサリ）
まぁ所詮「イジワルC++」ですから。
なんか、OrcasだとMFCも Vista対応されるんだな。
681 ：
デフォルトの名無しさん：2007/05/12(土) 18:26:10
mfcはそこそこosに近い所で動きながらそこそこラクができるのが
いいんじゃないの。CWndベースで何でも作れるやん。
あれだなんだっけ？
メモリデバイスコンテキストとかセレクトオブジェクトで取得したもんを
開放したり確保したりかってにやってくれるのがいい
アレ、自分でやると開放していいのか悪いのかさっぱりわからん
あと、トラッカークラスとかいいｗ
＞CWndベース
このクラス、Win32APIがくっついてるだけで、
変数も内部に保持しないわ、
楽にしてくれるメソッドは無いわ、
超スペシャルカス設計。
もともと、単なるラッパーとして設計されたクラスだもの。
＞単なるラッパー
いや、単なるラッパーでも内部に変数保持する筈だし、
便利なメソッドが付いてる筈。
㌧ﾃﾞﾓキチガイ設計だお。
MFCのステートのカオス度は異常
え？何を内部に変数保存するの？
よくわかんねーけどインスタンスだろ
CPenとか内部に保持してくれたりリリースしてくれたりしないのは変杉。
設計当時、GDI上のハンドルは全てキャッシュだからなぁ。
Win16/Win95時代の設計なんだよ。
だから、どうしても変な実装になる。
VCLならちゃんとした設計になってるよ。
各コントロールやウィンドウがCanvasっていう抽象クラスを持ってて、
Canvasクラスがペンやメソッド持ってるお。
apiを直に使うのに慣れてたら違和感ないだろう
apiとやり方が全然違うとかえって使いにくいし
＞apiを直に使うのに慣れてたら違和感ないだろう
違和感ありあり。
apiの機能を端折ることなくメソッド追加できるのが、クラスベース言語＆クラスライブラリ。
クラスライブラリが無ければ、apiのラップ自体が開発となるのに、
目の前にトンでも設計便利なところ無しクラスライブラリを目の前に置かれると目が点。
>691
その実装も問題ありだな。
つーか、OS/2だと、DCとPSって分けられてたって知ってる?
何がどう問題なのか書かなきゃ意味無し。
ほう、ドリキャスとプレステで分けられてたのか。
三千院家の屋敷みたいだな。
たまにはWFCのことも思い出してあげてください…
ちゃんとしたものが作れるのであれば、なんでもいいよ。
MFCだろうとVCLだろうと。
WTL最強
702 ：
デフォルトの名無しさん：2007/06/21(木) 16:15:40
えー、歴史を知ってる人はそんなに簡単に史上最悪とか言わないよー。
だって、必用があったから拡張されて複雑になるわけで、それなりの理由があるんだから。
こいつ只のMSアンチだろｗ
＞必用があったから拡張されて複雑になるわけで
MFCに関しては当初から複雑。
GUIに関してはプロジェクトを超えて使いまわし出来ない。
>>705 >GUIに関してはプロジェクトを超えて使いまわし出来ない。
まさか、リソースIDに整数使ってたりする？
そういう問題じゃなくて、
resource.hの存在自体がoop的にはトンでもキティなの。
歴史的にリソースは CのSDKからそのまま持ってきたんだから、oop的にキモいのは当たり前なんだよな。
MFCが当初から複雑って、16bit時代のMFCの事を指してる?
当初は簡単なモノだったさ。
＞MFCが当初から複雑って、16bit時代のMFCの事を指してる?
いや、今現在のヤツのダイアログ作成が超サイアク。
>709
最初のバージョンから比べると、今のダイアログ作成はかなり楽になった方だと思うけど。
最初のバージョンは、SDKのダイアログエディターしかなかったんだぜ。
＞最初のバージョンから比べると、今のダイアログ作成はかなり楽になった方だと思うけど。
その比較に何の意味がある。
＞最初のバージョンは、SDKのダイアログエディターしかなかったんだぜ。
ｲﾗﾈ
711は昔から常駐してるクソだから放置しとけ
歴史を知ってれば…って話前提なんだから、最初のバージョンの比較に意味はあるだろ。
このバカ。
現状がサイアクなのに、
＞最初のバージョンから比べると、今のダイアログ作成はかなり楽になった方だと思うけど。
といった内容に何の意味がある。
このバカ。
715 ：
デフォルトの名無しさん：2007/06/28(木) 14:15:10
> GUIに関してはプロジェクトを超えて使いまわし出来ない。
MFCベースで作成した拡張DLLで、複数のプロジェクトでGUIを共有
してますが、何か？
あの、それDLLの共有。
OOPでいうところの、ベースダイアログと派生ダイアログっていう共有じゃないでしょ。
ちょっと処理が違うダイアログ作ろうと思って、DLL変えてるようじゃoopじゃないから。
派生クラスを増やしても他の派生クラスのバグの元とならないことが重要。
717 ：
715：2007/06/28(木) 15:30:10
>>716 > OOPでいうところの、ベースダイアログと派生ダイアログっていう
> 共有じゃないでしょ。
それをやりたけりゃ、作成した独自ダイアログクラスを持つDLLから、
さらに別の拡張DLLなりアプリケーション側なりで、派生ダイアログ
クラスを定義すればいいだけでしょ？
そのやり方も知らないで、よくプログラマやってられるな～。それとも
口先だけの自称システムエンジニア様か、自称ITコンサル様？(w
> 派生クラスを増やしても他の派生クラスのバグの元とならないことが重要。
そんなもんクラス設計する側に依存する問題であって、MFCに依存の
問題じゃねぇだろが。
いるんだよな～。オープン厨房とか、自分のスキルや知識のなさを棚に
上げて、何か問題を起こすとWindowsやらMFCのせいにして、ひたすら
Unixの営業を始める香具師。
＞それをやりたけりゃ、作成した独自ダイアログクラスを持つDLLから、
＞さらに別の拡張DLLなりアプリケーション側なりで、派生ダイアログ
＞クラスを定義すればいいだけでしょ？
これって派生したダイアログ側でVC++のGUIでコントロール足せんやん。
出来ないことを出来るように書くな。
>>718 >これって派生したダイアログ側でVC++のGUIでコントロール足せんやん。
無茶しようとしてできなかったからMFC糞、という結論になったんですか。
722 ：
715：2007/06/28(木) 18:28:34
> これって派生したダイアログ側でVC++のGUIでコントロール足せんやん。
> 出来ないことを出来るように書くな。
無知とは、ホント恥ずかしいな。
何でこのスレの住人はこんなにも攻撃的なのだろうか。
MFCの有用性よりもそっちの方が気になる。
724 ：
715：2007/06/28(木) 21:53:13
クリエイターはＳ。(by 江川達也)
口先だけの自称ITコンサル様の俺が来ましたよ。モットーは生かさず殺さず。
さすがに、現状が最悪とか言って、くそみそ一緒にされてもな。
つーか、技術者のどこがクリエイター?
MFCってM$社内でさえ使われないくらい悪いものじゃん。
その後のWTLと共にアナウンスではメジャーバージョンうｐ停止。
実際にはうｐされたけどさ。
しかしだ、ドトネトに逝こう汁とは、いかがなものかと。
C++/CLIも最悪だしねぇ。C#は体感遅いし。
結局、C++と .Netは層を分けて設計するのがベストかねぇ。
>>722 プログラムから追加するだけなら出来て当たり前なんだから、
>>718 はもっと凄いことを要求してんじゃね？
「基底クラスのデザインがダイアログエディタで編集できないじゃねーか！」
とかさ。
＞「基底クラスのデザインがダイアログエディタで編集できないじゃねーか！」
これって、C++Builderだとふつーに出来るじゃん。
メソッドのオーバーライドは当たり前として、イベントハンドラのオーバーライドも出来るお。
732 ：
722：2007/06/29(金) 12:14:39
>>730 その可能性は考えた。けど、
>>718 と同一人物かどうか判らんけど
>>720 では ...
> いや、MFC以外では出来るんだけど。
とハッキリ書いてるし、きっと違うんじゃないか？(w
> 「基底クラスのデザインがダイアログエディタで編集できないじゃねーか！」
だと、MFCに限らず、C++でダイアログリソース使うケースは全て該当する
ので、
>>720 と明らかに矛盾する。
ただし、プログラムでダイアログリソースを動的に生成してオブジェクト
作成時に、コンストラクタやCDialog::Create()に渡す仕掛けを自前で
提供すれば、MFCのCDialogクラスでも、できなくもない気がする。
いずれにしろ、継承されたリソースを記述したり、編集したりできない
のは、リソースエディタの仕様やデータ構造の問題でMFCとは無関係だろう。
733 ：
デフォルトの名無しさん：2007/06/29(金) 12:19:07
＞だと、MFCに限らず、C++でダイアログリソース使うケースは全て該当する
誰がどう見てもMFCのダイアログエディタがサイアクだろ。
734=あれがMFCと連動したMFC専用だという事を知らないMFC井の中の蛙
736 ：
722：2007/06/29(金) 13:41:27
思うに、
>>735 は、VBプログラマか、C++ Builderあたりでも使っていた
のだろうか？おそらく使いこなせていなかったと想像できるが。
少なくとも、リソースエディタが、MFC専用ではないことすら知らない
ようだ。そして、世の中には継承を記述できるリソースエディタが存在
するらしい。そんなモン見たことないけど。
737 ：
734：2007/06/29(金) 13:47:06
CreateDialogIndirect や CreateDialogParam ってのは API だと思っていたが
いやはや、MFC と連動しているとは知らなかった。
734=ゆとりMFC世代のM$脳
＞少なくとも、リソースエディタが、MFC専用ではないことすら知らない
DDX埋め込むからパーフェクトにMFC専用だよ。
722=ウソが平気
ああ、クラスウィザードと混同してんのか。間抜けだなあ。
741 ：
722：2007/06/29(金) 14:56:57
DDX埋め込む？ハァ？もしかして、DDX_Control()とか、DDX_Text()とか
のことか？ あれを自動でソースに埋め込んでいるのは、クラスウィ
ザードなわけで、リソースエディタではないわけだが？
きょうび、こんなヤツがプロジェクト仕切ってたりした日にゃ、どんな
簡単なプログラムさえリリースされることはあるまい。
歴史を知らないヤツほど、最悪という。
リソースエディタとクラスウィザード込みだから、
MFCのダイアログエディタと逝ってるだろうが。
それを勝手にミスリード：
＞MFCのダイアログエディタ
＞少なくとも、リソースエディタが、MFC専用ではないことすら知らない
こういう感じ。
間抜けだなあ。 ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
絶対揺るがない結論：
MFCのダイアログエディタ（リソースエディタ、クラスウィザード）は、
何をどう言い訳しても、超使い難い。
745 ：
722：2007/06/29(金) 15:35:05
>>743 統合環境では、MFCを使わないWin32 APIのみによるプロジェクトも作成
可能なわけだが、そのプロジェクト内でリソース編集には、リソースエデ
ィタを使わないのかぃ？(w
それに、MFC使っていようが、MFC使っていまいが、リソースのソースファ
イルの中身はテキストなので、普通にメモ帳とかで編集できるわけで、
おそらくそれさえも知らないのだろうな。
ここまで無知っぷりを晒すとは。貴重な反面教師として絶滅危惧種に指定
すべきだな。
ところで、MFC以外なら継承を記述できるという例を早く挙げてくれよ。
＞統合環境では、MFCを使わないWin32 APIのみによるプロジェクトも作成可能なわけだが、
＞そのプロジェクト内でリソース編集には、リソースエディタを使わないのかぃ？(w
＞MFC使っていようが、MFC使っていまいが、リソースのソースファイルの中身は
＞テキストなので、普通にメモ帳とかで編集できるわけで、
↑
これが、”何をどう言い訳しても”っていう中身ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
２回も同じことを書いて必死ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
やっぱり絶対揺るがない結論：
MFCのダイアログエディタ（リソースエディタ、クラスウィザード）は、
何をどう言い訳しても、超使い難い。
_, ._
（ ・ω・） 芝刈り機出動
○=｛=｝〇,
|:::::::::＼, ', ´
.ｗｗし ｗ`（.＠）ｗｗｗｗ
芝刈ってみました：
やっぱ、リソースエディタ形式を守るため、というのはいい訳だと思うんですよ。
なぜなら、MFCダイアログエディタでコントロール貼り付けたものをC言語で利用するかっていうと、そんな事やりません。
それよりも、GUIエディタ＋クラスライブラリでペタペタ貼り付けて、かつ、ジェネレートされるコードが少ない、ってのが一番。
ゆとりが一匹暴れてるのか
750 ：
722：2007/06/29(金) 16:08:52
ゆとりというより、キチガイだろう。
751 ：
722：2007/06/29(金) 16:17:19
> MFCダイアログエディタでコントロール貼り付けたものをC言語で利用するかっていうと、そんな事やりません。
こんなことを平気で書くくらいだから、そもそもMFCを使わず、C言語(API)
だけでダイアログを出す方法も知らないし、当然コードすら書けないんだろ
うな。
MFC自体は、マイクロソフト謹製という点を除けば、C++で書かれたクラス
ライブラリの1つに過ぎないし、完全なソースも付いていて、C++の基本が
正しく理解できてさえいれば、さほど悩むことはない。
＞> MFCダイアログエディタでコントロール貼り付けたものをC言語で利用するかっていうと、そんな事やりません。
＞こんなことを平気で書くくらいだから、そもそもMFCを使わず、C言語(API)
＞だけでダイアログを出す方法も知らないし、当然コードすら書けないんだろうな。
クラスライブラリを使う人間がC言語を使わない、というのは妥当な発言。
それに対して”こんなことを平気で書くくらいだから”なんて、これは言い掛かりがハゲし杉る。
こういうの”ゆとり”、”キチガイ”というのだろうか。
文脈に関係なけど、VC++1.0以前のMSC＆コマンドプロンプトででWin16アプリを作る時代から開発してまつ。
＞絶対揺るがない結論： MFCのダイアログエディタ（リソースエディタ、クラスウィザード）は、 何をどう言い訳しても、超使い難い。
こう書いているのに、
リソース形式の言い訳ばっかり（３回目ｗ）書いた上に、
＞MFC自体は、マイクロソフト謹製という点を除けば、C++で書かれたクラス
＞ライブラリの1つに過ぎないし、完全なソースも付いていて、C++の基本が
＞正しく理解できてさえいれば、さほど悩むことはない。
こういう文脈から外れた自分が上に立つための関係ないこと書き出して、イヤなヤツ杉る。
結論２：
MFCを使うとリソースの言い訳ばかりせざるを得ない。
嫌なヤツになる。
755 ：
722：2007/06/29(金) 16:40:52
> 文脈に関係なけど、VC++1.0以前のMSC＆コマンドプロンプトででWin16アプリを作る時代から開発してまつ。
それが、何か？ 漏れはCP/M-80の時代からプログラムやってるよ。
MFCのリソースエディタが嫌なら、CWndから全部自前でコントロールクラス
を作成し、XML形式でも何でも好きなフォーマットのリソース形式を自前
で定義して、それ用のGUIエディタでも何でも、好きに作ればよいだけ。
VBとか、まさにそんなもんだろ。
>>752-753 には一生掛かっても無理だろうけどナー。
MFC自体もマイクロソフトも、MFCを使うことを強制してはいない。
ところで、MFC以外なら継承を記述できるという例を早く挙げてくれよ。
＞>>そもそもMFCを使わず、C言語(API) だけでダイアログを出す方法も知らないし、当然コードすら書けないんだろ うな。
＞> 文脈に関係なけど、VC++1.0以前のMSC＆コマンドプロンプトででWin16アプリを作る時代から開発してまつ。
＞それが、何か？ 漏れはCP/M-80の時代からプログラムやってるよ。
この文脈に流れないように釘打っといたのに流れるヴぁかなヤシ。
＞MFCのリソースエディタが嫌なら、CWndから全部自前でコントロールクラス
＞を作成し、XML形式でも何でも好きなフォーマットのリソース形式を自前
＞で定義して、それ用のGUIエディタでも何でも、好きに作ればよいだけ。
＞VBとか、まさにそんなもんだろ。
氏滅したブビを出すなんてヴぁかなヤシｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
お前が知ってる世界はだっせー
＞MFC自体もマイクロソフトも、MFCを使うことを強制してはいない。
当たり前だろ、M＄社内でMFCなんてきちゃないもの使ってないよｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
お前はMFC使ってれば良いんだよｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
継承ﾏﾀﾞｰ？（AAｒｙ
再度指摘。
>MFCのダイアログエディタ
760 ：
722：2007/06/29(金) 17:07:07
君の言うＭ＄って、ＭＳＫＫのことか？
まぁ、あそこはＭＳ内部でも極めて特殊で、代理店統括みたいなコトしか
やってないから。ＭＳＫＫで過去に開発した製品って、はがきスタジオ
くらいだろ。実態は、偽装請負だけど。(w
MSDNも別会社に丸投げしてるしな。
MFCはアップデートされないんじゃなくて、既に出来上がってる部分は
バグが枯れているんだよ。それに、MFC使ってる香具師は、自前の派生
クラスライブラリくらい構築していると思われ。
＞再度指摘。
＞>MFCのダイアログエディタ
MFCのダイアログエディタ＝リソースエディタ＋クラスウィザード
＞君の言うＭ＄って、ＭＳＫＫのことか？
”君”ってｴﾗｿｰだね。
違う。本社。
＞継承ﾏﾀﾞｰ？（AAｒｙ
教えると損だから教えないことにした。
ダイアログエディタはクラスウィザードじゃねぇよ。馬鹿なんじゃないの?
少なくともこのスレでは、お前以外にMFCのダイアログエディタという言葉を使う奴はいないし、
そのように考える思考も持っていない。あくまでリソースエディタとクラスウィザードは、
（連携はするが）別の機能と捉えているはずだ。
だから話が噛み合わない。
764 ：
デフォルトの名無しさん：2007/06/29(金) 18:19:37
このスレで会話するためにMFCでダイアログを作るときの総称を、
”MFCのダイアログエディタ”と今ネーミングして、
その内訳が”リソースエディタ”と”クラスウィザード”って呼んでるわけ。
話の途中で突っかかってくる、ユトリ＆キティだね。
馬鹿なんじゃないの?
＞だから話が噛み合わない。
そりゃ、話を噛み合わせたら最後さ。
＞あくまでリソースエディタとクラスウィザードは、
＞（連携はするが）別の機能と捉えているはずだ。
これらの連携がちょー使い難いんだからｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
絶対揺るがない結論：
MFCのダイアログ作成（リソースエディタ、クラスウィザード）は、
リソースエディタ単体を見ようが、
クラスウィザード使って連携させようが、
何をどう言い訳しても、超使い難い。
つまりWin16由来のリソーススクリプトが糞であり再利用性や柔軟性を
阻む代物なのであって、オブジェクト指向らしく組みたいのなら、MFCのように
リソーススクリプトに依存しつづけるのではなく、
TkやJavaのようにGUIコンポーネントを常に動的に生成配置するように汁
ということかしら？
>>767 それが要望の１点目。
もう一つ、ジェネレートするコード量を減らして欲しい。
第三世代言語＋コードジェネレーターの問題点はジェネレートされたコードを背負う事で、
それに対する解決策が差分コーディング。
注意：差分コーディングはOOPの本質じゃない、という反論禁止。ここで言いたいのは別の話。
継承ﾏﾀﾞｰ？（AAｒｙ
で、
>>766 は、どこら辺が「超」使いづらいの?
ところでリソースファイルって無理やり１つのプロジェクトで複数呼ぶことってできるじゃん？
これってやっていいの？悪いの？
一応動くは動くんだけど・・・
複数人で開発してるとどうしても１つにまとめられてると不便でしょうがないんだよね
リソースファイル１つだと、
あるウィンドウ造ってライブラリみたいにしておいとくってできないじゃん
これが複数使えるようにすると結構便利になるんだが・・・
.rcと.rc2みたいにすりゃいいんじゃないの？
>>772 そうそうそうやってるんだけど
やっていいのか悪いのか判断がつかなくて・・・
で、
>>766 は、どこら辺が「超」使いづらいの?
なんかマクロ＋独自の変換ツールの記述が多くてかっこわり。
776 ：
デフォルトの名無しさん：2007/07/01(日) 19:15:42
複数人で開発するのに、機能単位で担当者を振り分け、機能毎にDLL化
したりせず、一本糞みたいに、1つの実行ファイルにしちゃうマネージ
メントが、MFC以前にまさに糞だと思うんだが？
１つの実行ファイルにするかどうかと、ちゃんと分割統治されてるかどうかは別の話だろ
>>776 機能毎にDLL化って何がいいの？
すげーバグつかみにくい上になにも分離できねぇと思うんだけど
779 ：
デフォルトの名無しさん：2007/07/01(日) 20:46:29
DLLに分割するのに必要な機能の洗い出しや切り分けをする能力も、DLLの
デバッグ手法に関する知識もないのに、まるで『DLL化していなければ、
たとえバグを出しても、すぐに見つけられる』とさえ言い出しかねない、
そんな
>>778 に、一言どうぞ。
↓
単純に設定とか面倒じゃんｗ
デバッグ版DLL
リリース版DLL
なんだかコンパイルオプションの設定が違っちゃったデバッグ版DLL
なんだかコンパイルオプションの設定が違っちゃったリリース版DLL
とかなり面倒で死んだｗ
プログラム以前の問題だった
こんなところで躓いてるわけにはいかないと思った
ひとつのプロジェクトでしか使用せず
再利用の機会がないDLLなら分割するメリットはない
単一の実行ファイルにしてしまっても問題ない
OSのAPI等のように複数のプログラムから共通に利用されて
初めてDLLにした意味が出てくる
782 ：
デフォルトの名無しさん：2007/07/01(日) 21:26:11
そして数多のMSVCRTが混在しましたとさ
libも凶悪だよな
作者がなんも知らんで公開しててコンパイルオプションが
違うからコンパイルできんとかアリガチ
デバッグ版で配ってるとかよｗ
プログラムはソースで配布すべき
そこでLGPLですよ
#GPLv3公開されましたね
786 ：
デフォルトの名無しさん：2007/07/01(日) 22:48:32
で、
>>766 は、どこら辺が「超」使いづらいの?
>>784 俺はこれは反対だ。
ついうっかり1文字書き換えちゃっただけで終了
>>784 てか、あれ、バージョン管理を設置するべきだよね
>>787 そういうときのためにMD5がある訳だが
っつーかバイナリ配布でも１バイト書き換えたら死ぬだろ
790 ：
デフォルトの名無しさん：2007/07/04(水) 09:00:12
>>789 MSって、ISOイメージを丸ごとダウンロードさせる場合でも、MD5値とか
正確なファイルサイズを公開していないケース多くない？
792 ：
デフォルトの名無しさん：2007/10/10(水) 01:02:25
今更MFCつかったけど、糞だな
ダイアログベースじゃなきゃ、UI全て手書きかよ・・・
なんだこりゃ
MFC使うのと、API直接いじるのとでは、難易度はどのくらい違いますか？
APIはマニュアルみて使い方理解するだけだから簡単
MFCの方はAPIとの整合性を考えながら使わないといけないから面倒
APIを薦める
795 ：
デフォルトの名無しさん：2007/11/09(金) 15:58:34
結局APIを調べることって必要になるんだよね。
796 ：
デフォルトの名無しさん：2007/11/09(金) 16:04:19
MFCって、消えてなくなるの？
今さら勉強しても無駄無意味？
勉強したら悪いデザインが身に付くが。
例えば、
クラスライブラリなのに巨大なコードが吐き出されるとか、
ダイアログ部品少ないし部品がActiveXじゃ素直に派生できないとか、
ダイアログ作り難杉でやりたいことよりダイアログの記述が多いよとか、
結局描画するだけでもＡＰＩコール、
みたいな。
アンチMFCなひとは
wxWidgets
gtkmm
FOX
その他
どれ使ってます？
799 ：
デフォルトの名無しさん：2007/11/10(土) 03:39:05
.net
>>793 生API使っても、見栄えのするGUIを作るのはめちゃくちゃ大変だぞ。
801 ：
デフォルトの名無しさん：2007/11/10(土) 03:57:00
MFCってダイアログしか作れないんでしょ？バカみたい。
802 ：
デフォルトの名無しさん：2007/11/10(土) 05:38:00
はぁ？
そろそろ完全に切り捨てないのかね
いつまでも使おうとする人がいて困る
805 ：
デフォルトの名無しさん：2007/11/11(日) 00:46:09
ウィンドウの上半分をグラフ表示、下半分をリスト表示の画面を作るだけで
３０分もかかった・・・
なんて生産性の低いツールだよ・・・
806 ：
デフォルトの名無しさん：2007/11/11(日) 01:07:54
MFCみたいなライブラリはMSの小遣い稼ぎだろ。
技術に弱いけど知ったかが好きなIT企業経営者に
「MFCってのがあるらしい。これで作ると基本的なクラスはすでに提供されていて生産効率が上がるらしい。」
みたいな勘違いをさせて、ライブラリを売りつけているだけだろ。
うたい文句には誰かが騙されるものだ。エンドユーザーかもしれないし、一次受け企業の営業かもしれない。
「お金を出すから新しいライブラリで、既存のプログラムを書き直そう。」誰かがそういって犠牲者になる。
しかし本当のしわ寄せは一番末端の開発者に来る。
生産効率など上がるわけも無く、落とし穴に嵌り、それを力技で回避して息も絶え絶えに納品されたプロジェクト
つぎはぎだらけになったソースコード。
企業はそれをソフトウエア資産だとおもって再利用することに固執し、さらに生産効率が下がる。
赤字プロジェクトになり、開発者がサービス残業や、ボーナスカット、解雇といったしわ寄せを食う。
そのライブラリを作った詐欺集団の開発者は快適なオフィスで如何にMFCがすばらしいか、コラムを書いている。
つまらないアメリカンジョークも飛び出す、そんなコラムだ。
化けの皮が剥がれるころには次のフレームワークがリリースされている。
なんだこりゃ？１０年前のコピペか？？
808 ：
デフォルトの名無しさん：2007/11/11(日) 01:55:26
まあ確かにオブジェクト指向だ、再利用だといっても、C++担ってからのほうがさらに
メンテが面倒になった気はする。
テンプレートとか消滅して欲しい。
809 ：
デフォルトの名無しさん：2007/11/11(日) 02:55:02
>>806 釣りっぽいが、MFC使った方が生APIだけで作るより遥かに生産性高いよ
MFCやSTL、Boost、ATLも適所に使えばソースがかなり簡略化される
ソース再利用はライブラリがどうこうの話じゃなく、自分の問題だろ
自分で再利用可能なように作らず、汚いソース書いてるから再利用できないだけ
まぁ、後々まで考えて、再利用可能にする工数を会社が出さないもの一因だと思うけどな
ただゲームみたいな速度重視なら余計な被りものはデットウェイトになるのかな
業務系ならライブラリは十分使える
>>798 wxWidgets使っている。見た目も商用的に負けてない。
一度書いたGUIは、プログラムと完全に分離できるから資産化できるよ。
問題は英語の壁と、無料の拡張WidgetがUnicodeに対応していないことがある事。
自分的に気に入った点は、C/C++でめんどくさくなったらperl/pythonでも書けること。
811 ：
810：2007/11/11(日) 04:02:44
>>809 たしかに有効である場面もあるんだけど大事な部分が抜けてるクラスとか多い気が
結局生APIいじる必要あったりしてそれを調べた分を考えると生産性が似たりよったり
まあ既に機能把握して使いこなしてるんだったら圧倒的に生産性高いのは認める
ただ会社の都合上すぐDLL化しろいいやがるのでMFC DLLを使うことになるのが鬱
VCLみたいな便利なクラスライブラリではなく
単なるAPIの薄いラッパーだということに気付いた15の夜
そうそう、ＭＦＣはクラスライブラリじゃなくてＡＰＩラッパー。
ラップにところどころ穴があってＡＰＩコールが必要orz
815 ：
デフォルトの名無しさん：2007/11/11(日) 09:42:33
.NETはほんとうに美しい！！！
心もソースも洗われますよ。
MFCは
謎解きの荒らしなんで勘弁。
>>815 .NETは悪くない、寧ろMFCでCOMとか扱う苦労を考えたら .NET 最高っ、とか思う
ただ一点どうしても気に入らない部分がある
サブスレッドからコントロールを弄る時に…BeginInvoke()
こればっかりは簡便してくれと、なんかうまい手あんのかな
エディットコントロールの中身が実はウィンドウのタイトルバーを流用したものだと
独力で突き止めるのに半年かけたあの頃
Σ (ﾟДﾟ;）ﾊｯ この流れもしやDelphiオンリー？
まあMFCは重いってのも嫌われる理由かと
WTL使ってみるといいよ、かなり軽い
俺的には生API叩いてるのと大して変わらないと思うんだけどどうなんだろうか
820 ：
デフォルトの名無しさん：2007/11/11(日) 23:27:32
.NETってインタプリタじゃん。コンパイラ言語と比べるなよ。
無知乙
？
JIT経由になるってだけで最終的にはネイティブだろ
823 ：
デフォルトの名無しさん：2007/11/12(月) 00:48:53
働けど、働けど、バグ取れず
JIT手を見る。
824 ：
デフォルトの名無しさん：2007/11/12(月) 16:29:03
ガベージコレクションのあるネイティブコンパイラなんて存在するのか？
いったいどんなコードにコンパイルされんの？
つD言語
＞ガベージコレクション
クラスのローカル変数としての実体宣言オブジェクト
IDEは凄いけど、中の人のMFCはダサいでしょ。
ってActiveX以外のコントロールを沢山使えるようになるとか、
中の人が丸々変わるんなら気体だけど。
age
age
832 ：
デフォルトの名無しさん：2007/12/29(土) 01:48:16
MFCのクラス設計はクソだが、普通に使える。
コアなことやろうとしてもビルダーじゃどうにもならないしな。
＞MFCのクラス設計はクソだが、普通に使える。
これは絶対に無いというのが、ここまでのレス。
＞コアなことやろうとしてもビルダーじゃどうにもならないしな。
意味踏め
ムキになるなよ
MFC使ってマルチスレッドで痛い目見たから個人的にMFCは嫌い
普通のアプリには使える。
コアなことやろうとするとC++Builderじゃつらいしな。
って言いたいんじゃまいか？
同意はできないけど。
＞普通のアプリには使える。
無理。
だって、強制MDIでサイズ不変ののっぺらアプリになりがち。
＞コアなことやろうとするとC++Builderじゃつらいしな。
絶対無い。
837 ：
デフォルトの名無しさん：2008/01/09(水) 19:48:23
>>836 別に、既存のクラスやフレームワークをそのまま使わず、好きにオレ様
仕様のDoc-Viewでも実装すればいいだろう。
C++ Builderって、そもそも未来がないだろ。
838 ：
デフォルトの名無しさん：2008/01/09(水) 20:33:37
オレ様仕様を実装するならMFC使う意味ね～～～ぢゃん！
839 ：
デフォルトの名無しさん：2008/01/10(木) 00:59:21
>>838 そういうのは、まともにクラスの実装ができるようになってから言え。
結局、『MFCが使えない』と言っている本人自身が、「本当に使えない
ヤツ」ってことだろ？
840 ：
デフォルトの名無しさん：2008/01/10(木) 01:39:33
>>834 MFCの同期オブジェクトの動きに翻弄された記憶があるので同意
スレッドに関してはAPI生で使った方が使いやすかった
一番汚いのはMFCで画面作成。
作りにくい、出来上がりがノッペラ。
＞好きにオレ様 仕様のDoc-Viewでも実装
この内容って実は正しくて、Docに関してはフレームワークが勝手に弄ると、Docの中に処理を隠蔽するという事ができなくなる。
Doc-View間の連携はvectorへの参照程度なので、フレームワークが管理してくれる必要は無い。
843 ：
デフォルトの名無しさん：2008/01/10(木) 15:43:32
>>839 × MFCが使えない
○ MFCは使えない
アンダースタンド？
マイクロソフト フライド チキン
845 ：
デフォルトの名無しさん：2008/01/10(木) 21:21:18
マイクロソフト イズ チキン
846 ：
デフォルトの名無しさん：2008/01/11(金) 07:24:41
MFCに慣れてるけど、VistaやWindows7になったらイヤでも.NETを使わざる終えないのかな？
もしかして: 使わざるを得ない
いや２ちゃん語かとは思ったが。
MFCは終わるだろうけど、ドトネトはスルーしる！
そのうち、ドトネ一色になるだろう。
その前にＭ＄がドトネト利用をアキラメタ。
オフィスとか。
でもクライアント企業は一度はまったら簡単には抜けられそうにないな
みんなそれに気付いたから、旧ブイビーに留まるか、ウェブ系に逃げてドトネトしないわけさ。
854 ：
デフォルトの名無しさん：2008/01/11(金) 21:42:29
ドドメ色
そうかねえ
もっと早く.NET Frameworkを標準搭載するべきだったと思うんだが
MFCの.NETラッパーが出て出て出てく出てく出てく出てくる
それってぐちゃぐちゃ。
Win32コードとAxをドトネトでラップなんて、中の人を追いかけるだけでしんどい。
MFCがいいところは、デバッグができるところだな。
Doc-Viewなんて使わなくても問題ないお
逆に商用でデバッグできないもんがあれば、教えてくれ！
VC++/MFCだとエラーダイアログが出て次の行をトレースできなくて困るけどね。
他のコンパイラならthrowしてるところでデバッガがステイしててくれる。
age
>>857 Windows FormsをホストするCWinFormsViewなら既にある。
ここまで読んで、VCLが非常に優れてるのはわかったけど
なんで死んでしまったん？
.NETで作ると、客先から「起動が遅い、何とかならんのか？」って必ずクレームが来ることを
覚悟して出荷せにゃならん
それは作りが
>>863 氏んだんじゃない。
VC++に搭載されないだけ。
VCLのパチモンはドトネトとして搭載されたけど、モッサリ（ｒｙ
C++/MFC去年はじめたけどカッコよすぎだろコレｗ
って思う俺はヘンなのか
ま、良んじゃない？
何食べてもおいしい人でしょ。
逆説的にとry
CArrayってサイズを拡張するとき、旧テーブル上のデータに対してデストラクタを呼ばずに
memsetで新しい配列にバイナリ・コピーするんだね(´ー｀)
おかげでコンストラクタとデストラクタでthisの値が変わるとかいう現象が起こって
デバッグに半日つぶしたよ。死ねよ頼むから(´∀｀ )
デストラクタ発動もそれはそれでマズい
生成破棄に処理が伴うとか、あとウィンドウ登録される類の気を遣うべきクラスを格納するなら
CObject*やvoid*用のArrayやListでポインタだけ扱った方がいい
>>870 >CArrayって
標準コンテナ使わず、そんなうんこ臭いもん使うからだ。
MFCのビュー/ドキュメントがあまり好きではない
というか邪魔というか
かといってプロジェクト作成でドキュメント否定するとビューすら使わせてくれないのよね
デフォだと子ビュー的な名前のCWnd派生が出来る。ちょっとイヤ。手動で作れ。
874 ：
デフォルトの名無しさん：2008/04/06(日) 11:26:58
もともとはマイクロソフトがワードやエクセルを開発するために、こしらえたもんだからな。
その余った部品をＭＦＣとしてリリースしちまったんだ。
ワードやエクセルみたいなアプリを作るには良いかもしれんが
世の中すべてのアプリがそうとは限らない。
ＭＦＣが発表されたころはＭＤＩアプリ全盛期だったが
その後Windows９５とともにＳＤＩが流行しはじめると
ＭＦＣがクソで使い物にならん事に気づいた。
ＭＦＣに見切りをつけてデルファイに流れた者もいた。
あれから１０年以上も経って、まだＭＦＣ使ってるヤツおるんか・・・
Wordでさえ今はSDIだもんな
ExcelもさっさとSDIになってくれればいいのに
タブブラウザ全盛ですよ
MDIはapiレベルで実現してる機能だろ
何でＳＤＩが流行しはじめるとＭＦＣがクソなんだ？
そうだぜ、MDI・SDIに関係なくMFCは糞だ
なんか大事な部分が抜け落ちたりしてるので結局自前で実装したりする部分が多すぎる
MDI・SDIなんて何つくるかにも依るとは思うけど
基本的にアプリ開発選択でデフォにしておくものではないよなぁ。MDI
あとVBチックなダイアログベースアプリも簡単に作れはするけど
WinAppの初期起動中にアプリ（CDialog）寿命完結するというなんかイレギュラー臭い仕様が気になるｗ
今からＣ++とＭＦＣをゼロから勉強するのって意味ないでしょうか？
医者になるんだったら意味無いな
C++は勉強しる。
883 ：
デフォルトの名無しさん：2008/04/14(月) 22:16:00
>>880 目的は？
C++とかMFCとかは手段なのだから、目的に応じてやればよいこと。
プログラムの勘所がわかれば環境なんてどーにでもなる。
resource.hも
.rcも結局直にいぢるハメになり余計な時間を喰っちまうぞボケー
885 ：
デフォルトの名無しさん：2008/04/14(月) 23:45:49
学校の課題？
＞環境なんてどーにでもなる。
どーにでもならないのがMFC。
プロジェクト超えてふつーにダイアログを派生とかで使い回しできないのには超まいる。
887 ：
デフォルトの名無しさん：2008/04/15(火) 23:07:24
>>886 発言の意味を理解してないのにコメントすんなってｗ
>ダイアログを派生とかで使い回しできない
拡張DLLがそんなにいやなのか。
そりゃ、超ヤダよ。
ダイアログはCDialogから派生になってるんだから、あるダイアログをプロジェクト毎に派生して使いたいだろ、常考。
自分で派生クラス作れんのか( ´ω`) そりゃ苦労するな
既存部品の派生でないとマトモに扱ってもらえないが
その派生元の既存部品の内部処理から来る妙な仕様とかを知ってないと
意味不明のバグとか出しやがる
学校でプログラミングしてたら先生に「なんでMFC使ってないの？」って聞かれたから
「MFCってめんどくさそうで使ってないんです。」って応えたら
「最初から自分で作るより早いし便利だよ。」と言われた
なんかMFCって自由を奪われてる感じがして気持ち悪いんだが、
俺はMFCを覚えたほうがいいのかな？
いいえ。。。
↑番号がゴクドー
>>892 既存ライブラリを使ってプログラミングすれば、その流儀に合わせなくっちゃならない。
自由を奪われる感じはあって当然。
なので、自由を奪われてる感じがして気持ち悪いことを理由にしていたら、どんな既存ライブラリも使えない。
ずっとこの先、一人でプログラミングしていくつもりなら、俺様クラスライブラリを作ればいいやん。がんばれ。
＞俺様クラスライブラリ
この傾向が強すぎるのがＭＦＣ。
他環境で使えないし、WinでもつかえねーやつだからＭ＄社内でも別のクラスライブラリが作られた。
関わらないがよし。
単なるC++ラッパだからな
使いにくくて当然
えーっと、皆さん。
Visual Studioで使える、MFC以外のC++ クラスライブラリって何をお使いでしょうか。
.NET Framework(笑)
じゃなくてこうか？
ATL
WTL
STL
Boost
Loki port
Blitz++
Xerces C++
901 ：
デフォルトの名無しさん：2008/05/03(土) 23:44:37
いや、名前だけ知ってるのをリストアップしろってんじゃ無く、
自分がどれを使ってるか、ってのを聞きたいんじゃないかな？
WTL使えばMFC使う気なくなるな
けど、WTLってあんましメンテされてないように思うんだけど…。
ATLのバージョン毎にマクロがきられすぎてて、どう書けば正しいのかが
さっぱり…。
MFCも2008FeaturePackの多言語版(SP1)がつけば一気に盛り上がるんでは？
>>901 一応利用経験あるライブラリしか列挙してないが
>>904 齧ったのを使っているとは言わないです。
それでもBoostまでは普通に常用してるわ
OWLってなかったっけ？
それ昔のTurbo C++
>>908 昔のTurbo C++ってDOS版だよな。 ソレに付いてたの確かTurbo Visionだぞ。
OWLはBorland C++になってからWindows対応クラスライブラリとして添付されたはず。
gethtmlwのWindow ClassがOWL_Windowになってるな。
ロクに使ったことないけどQtの方がキュートty(形容詞)だな。
MFCでいいじゃん
MFCってｗｗ
クロスプラットフォームを意識するならwxWidgets
意識しなくてもwxWidgetsかQtのほうがMFCより作りやすい気がする
分かったからwxWidgetsとQtのどちらが良いか教えてくれ。
自分で試せよ
どっちも触ったこと無いけど、名前の感じがいいからwxWidgetsで
919 ：
デフォルトの名無しさん：2008/07/09(水) 00:01:51
MFCってそんなに使い勝手悪いかな？
VCLやwxWidgetsよりは間違いなく使いやすい
920 ：
デフォルトの名無しさん：2008/07/09(水) 00:51:34
DirectXもそのたSDKも全部統合して欲しいです＞＜
Win32 APIに明るい人ならMFCわかりやすいかもね
オブジェクト指向ではなくて単なる「便利なC」だけどな
いや。分かりにくい
「MSの想定した使い方をする限りでは楽ではあるが
そこから離れようとするとえらい労力を使わされる」
てとこだな。
MFCが使いやすいって言ってる奴は、
オブジェクト指向思考してないんじゃなかろーか。
違うかな？
16ビットの頃から C で書いてきた延長でそのまま使ってるからだよ。
適当に考えなしで使えるフレームワークとしていいべ
MSの想定した使い方なら確かに動くし、ある意味簡単
でも、それって、知ってれば簡単に書けるだけで調べるには骨が折れる。
結局覚えたら簡単ですよっていうレベル。
ならWin32でもおなじこっちゃ。覚えりゃ簡単です
MFCの悪いところは、「本当に意図したとおりに動くの？」の見極め作業がいること。
結局MFCソースみないと確信が持てない
変な動きをし始めちゃったら、結局MFCがどういうカラクリなのか調べる事に。この作業のほうがデカイ。
そして結構使っちゃいけないクラスとかある（あった）
ヘルプで良いことがいっぱい書いてあるから便利にラッピングしてくれてるのか？
と期待するが、そんな期待があたったためしもなし。CSocketとか。
結局Win32のめんどい手続きはそのまま隠蔽化しているクラスが
同じ程度の煩雑なメソッドで置き換えているだけ。
だったら最初からWin32で書いたほうがええっちゅーねん。
927 ：
デフォルトの名無しさん：2008/07/09(水) 19:21:38
WTL
J++用にWFCってのがあった記憶
ドトネトには〃
※以下、無限ループ
929 ：
デフォルトの名無しさん：2008/08/08(金) 17:13:22
MFCは何というか。。。
・Appwizard(コードジェネレータ)が生成した部分とユーザがコーディング
した部分の区別がつかない(せめて色分けしてくれるオプションがあったら
いいのに)
・普通ユーザがいじくるはずもない詳細な部分のコードまでさらけ出し過ぎ
・CdialogベースとCViewベース、SDIとMDIを最初の段階できめたら
途中で変更するのが難しい。
・同じ型を開発グループごとにtypedefで別々の型名使っているため
混乱する。
・ヘルプファイル見て調べろというけどHelpファイルは自動英訳ソフト
で変換したんじゃないかというくらい日本語になってない。わけわからん
解説よりも簡単なサンプルプログラムを乗せとけ！
フォームやダイアログのサイズ、背景色、コントロールの色などを変更する、
といった要求はごく普通なことだと思うのだが、プロパティシートにそう
いうパラメータを設定する項目がない。プログラムで変更しなければなら
ない。逆に、枠に境界線を設けるとか、３次元的に表示するとか、しょーも
ない項目しかプロパティシートに乗ってない、MFC作った奴は一体どういう
頭してたんだと腹が立つ。
・ちょっと｢こういうことがしたい｣と思っても簡単にはできない。MSDNを
調べても該当の箇所にヒットするのが難しい、ことばがわかりにくい。
結局、MSDNは諦めてgoogleや掲示板で調べるしかない。
正直、C#と比べると、時代遅れ。
懐かしいスレが上がってるな
C++ビルダーがいいよ
英語読めないでソフト作ってる人って頭おかしいの？
932 ：
デフォルトの名無しさん：2008/08/08(金) 22:55:06
>>929 ＞・CdialogベースとCViewベース、SDIとMDIを最初の段階できめたら
＞途中で変更するのが難しい。
そんなの必要か？
普通コーディングに入る前に十分な設計/検討をし、DRもやってから
コーディングに入った時点で変更なんてほぼありえないし、あっちゃまずい
>>932 そういうのが簡単にできないのが関数開発とかウォーターフォール。
オブジェクトのプロパティ変えるだけでできるべき。
934 ：
デフォルトの名無しさん：2008/08/08(金) 23:54:13
日曜プログラマな俺にはMSのIDEの出来は素晴らしいと思う
935 ：
デフォルトの名無しさん：2008/08/08(金) 23:55:01
簡単に変えれるかどうかが問題ではなく、基本設計をコーディングの際に変更がまずい
コーディングなんてのは現場の土方にでもやらせてればいい
土方に簡単に変更なんざできるはずない
936 ：
デフォルトの名無しさん：2008/08/09(土) 00:57:54
>>935 それ
>>932が言ったよ。
俺日曜PGだから分からんけどSEもPGも土方だよね？
PM以外みんな土方じゃないの？
そもそも１年や２年でモノ作れるようになれる業界じゃぁお金握ってる人以外皆同じでしょ？
937 ：
デフォルトの名無しさん：2008/08/09(土) 15:44:08
っていうか、そういう開発工程の話じゃなくて
仕事で軽く使えるツール作るとか、ちょっとした個人用アプリ作るとかのときに
手軽に簡単に使えるのがライブラリってもんだろと俺は思う
だからこそ、appwizardでMDI/SDIが簡単に選べたりすうんだし
>>936 違うよ。
たとえば建設関係で言えば、設計士は設計、施工管理もやるし
現場の作業の内容も把握している。
でもＰＭはたたき上げでもないかぎり進捗管理くらいしかできない。
939 ：
デフォルトの名無しさん：2008/08/09(土) 16:46:07
MFCが手軽とはとても思えない。SDKやったことがある人はわかるだろうし、
ありがたみもわかるんだろうけど、これを初心者が使いこなすのはしんどい。
ある程度のテクニックをもった人がそばにいてヒントを与えてくれるなら
いいが。
「プロパティが無い」だの「そばにいてヒント」だの・・・
・・・あ、夏休みか・・・
そもそもWindowsのGUIが扱いづらすぎる
せめて.NET風に扱えるライブラリがあればなあ
942 ：
デフォルトの名無しさん：2008/08/09(土) 17:10:57
.NET をつかえばいいじゃないか。
MS は MFC より .NET を推進したいんだろうから。
>>939 気軽に聞けるある程度のテクニックをもった人がいない初心者が、
いきなり"MFCを使いこなせる"と思うほうが変だろう。
それはSTLでもboostでも同じことに思えるし。
使わなければならない人や、（使わないより）使ったほうが楽だと思える場合だけ、
七転八倒すればいいだけじゃね？
944 ：
939：2008/08/09(土) 17:13:52
気軽に聞けるある程度のテクニックをもった人がいない初心者が、
を
気軽に聞ける「ある程度のテクニックをもった人」がいない初心者が、
に訂正、、しても読みにくいか。 まぁいいや。
>>939 えー。俺一人でMFC使えるようになったよ。
MFC Internalとか読んでMSDNと格闘しただけで普通に使えるよ。
これだから日本の職業SEPGは無能なんだよ。
>WindowsのGUIが扱いづらすぎる
X Window Systemの方が遥かに大変です
947 ：
デフォルトの名無しさん：2008/08/10(日) 15:48:52
>>944 なり済まし乙
>>940 いいから、もう夏休みとれ。あっ、残業で休みもろくにとれないか。
ゴクロウｗ
>MFC Internalとか読んでMSDNと格闘しただけで普通に使えるよ。
↑
使えない道具を使えないと理解できないどしろーと。
料理でいえば何食べてもおんなじ人。
Ｍ＄社内でさえ使われずに終焉したＭＦＣの次スレはイランだろｗ
>Ｍ＄社内でさえ使われずに終焉したＭＦＣの次スレはイランだろｗ
いろいろな意味でアホやね。
ほんとそーだね。
Ｍ＄社内で使われなかったものを使うのもアホ、
メジャーバージョンうｐを表明されて終焉したＭＦＣを使うのもアホ、
ＭＦＣをかばうのもアホｗ
恥の上塗りってやつ？
そうそう、嫌気がさしたスレでＭＦＣをかばうのは恥の上塗りｗｗｗ
夏休みらしいレス・・・もうちょっと冷静になって自分の書いたもの読んでごらん。
↑
内容では反論できない超ヴぁかｗｗｗｗｗ
自分が理解できないものは、いろいろと貶したくなるものだね。
↑
恥の上塗りってやつ？ ｗｗｗｗｗｗｗｗｗｗ
わかります。優しく同情されると悔しいですね。
草を生やして誤魔化してみたくなるものです。
↑
夏休みらしいレス・・・もうちょっと冷静になって自分の書いたもの読んでごらん。 ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
え? MFCを使えない?
あれぐらいサラッと使えるでしょーに。
960 ：
デフォルトの名無しさん：2008/08/11(月) 18:15:19
はいはい。あんな、つまらんものを使えるって言う馬鹿はいったい
Sour Grapes
「つまらんものを使えるって言う馬鹿」と「つまらんものを使うって言う馬鹿」
の間には大きな隔たりがあるのだと再認識しました。
M$脳って怖いね。
推奨がどんどん変わり続けて消えていってるのに気がつかないんだろうかね。
964 ：
デフォルトの名無しさん：2008/08/11(月) 18:29:55
どうすればいいんだ！
つ C++ Builder
966 ：
デフォルトの名無しさん：2008/08/11(月) 18:34:15
いまさら
でもない
「M$」みたいに手垢のついた表現を臆面もなしにする人ってなんだろな。
「M$脳って怖いね」なんて書いているのに、Windowsべったりな人って馬鹿を超越しているね。
968＝M$脳
>C++ Builder
吹いた
>>963って、Microsoftの推奨を追っかけていて、それに忠実であろうとしている人なんだね。
ＭＦＣはMicrosoftの推奨でもないし、
ペタペタ貼り難いし、
メジャーバージョンうｐオワタし、
何の目的で使う？？？
もう終わったんでつよ、ＭＦＣは？
ＭＦＣに関するソースも終わるってことですよ、ＶＢのように？
>ＭＦＣに関するソースも終わるってことですよ
日本語でOK
MFCは終わりました。
Visual Studio 2008でかなり強化されて、そのあとも Feature Pack がリリースされてるわけで。
それにしても笑った。→ペタペタ貼り難いし
それにしても笑った。→Visual Studio 2008でかなり強化されて、そのあとも Feature Pack がリリースされてるわけで。
いつまでもゴミ駄目のＭＦＣにしがみ付いてちゃダメだよ。
痛い粘着が湧いてるな
>>979 1000近づいているし、埋めネタにはちょうど良かったじゃないか。
あとはあほが次スレ立てなければ問題ない。
981 ：
デフォルトの名無しさん：2008/08/11(月) 22:53:24
MFCを糞なんていう奴って挫折しただけでしょ？
事実上デファクトスタンダードだろ
FA業界じゃ、.NETなんて使い物にならん
982 ：
デフォルトの名無しさん：2008/08/11(月) 23:26:07
所詮MFCを使いこなせなかった厨房がほざいてるだけですよ
WTL使おうぜ！
と言いたいところだがUIにもこだわらないといけない時代にはちょっと厳しいか
984 ：
デフォルトの名無しさん：2008/08/12(火) 00:09:38
MFCとかOTLとかわけわかんねぇ！
なんつーかな。
MFCを使いこなせる、こなせないの問題じゃないよね。
ここに来てる人は、みんな使いこなしてるだろーよ。
だけど、世の中にはもっとすぐれたライブラリもあるわけで。
そういうライブラリがデファクトになった方が、よりハッピーになれるじゃん。
そう思わねぇ？？？
>>985 >だけど、世の中にはもっとすぐれたライブラリもあるわけで。
例えば？
馬鹿にレスすんなよ馬鹿が
WxWigets, Qt, VCL, etc...
ああ。やっぱり。
じゃ、MFC捨てるわ。
【ソフト】米MS、Visual Studio 2008/ .NET Framework 3.5のSP1提供開始［08/08/12］
ttp://news24.2ch.net/test/read.cgi/bizplus/1218505964/ 2 名前： 名刺は切らしておりまして [sage] 投稿日： 2008/08/12(火) 10:53:39 ID:J4pMZFl6
＞.NET Framework
重いっちゅうのっ
3 名前： 名刺は切らしておりまして [sage] 投稿日： 2008/08/12(火) 10:57:33 ID:iqsKwHP2
普通にいらないと思う
4 名前： 名刺は切らしておりまして [sage] 投稿日： 2008/08/12(火) 10:59:51 ID:QZ8L4yYi
>再配布用のモジュールサイズを従来の197MB・・・
ふざけてるの？
5 名前： 名刺は切らしておりまして 投稿日： 2008/08/12(火) 11:04:39 ID:GYvNla61
Vista専用か
6 名前： 名刺は切らしておりまして 投稿日： 2008/08/12(火) 11:09:52 ID:sp4dzBNs
次々バージョンアップするし当初予定してたように自動アップデートしないし
ＶＢランタイムの二の舞になりつつあるなあ …最悪具合はそれ以上やね
7 名前： 名刺は切らしておりまして [sage] 投稿日： 2008/08/12(火) 11:12:48 ID:MIuWB666
>>6 Welcome to DLL Hell ! wpf ちん大ピンチッ!!
8 名前： 名刺は切らしておりまして [sage] 投稿日： 2008/08/12(火) 11:13:19 ID:o0tf+btN
C++の並列コンパイルいいよ。 2003と比べて3分の1ぐらいになった。 それでも2時間かかるけど。
9 名前： 名刺は切らしておりまして 投稿日： 2008/08/12(火) 11:13:38 ID:noCIOojl
どうせセキュリティ強化という名のバグ修正だろ
994 ：
デフォルトの名無しさん：2008/08/12(火) 15:41:16
中途半端に.NET普及させるのヤメテ！
やるならやるで、これしか選択肢が無いという状況に追い込んでくれ
MFCからどれに移行すればいいんだ・・・
>>995 それは、.NET Framework使えと？
それとも、フューチャーなんたら？
次スレ：
【V$ﾌﾖｰ】MFCから何に移行したらおｋ？【ﾄﾞﾄﾈﾄﾌﾖｰ】
開発ツールとか企業がネットで配布するツールとか見てるが、
昔のものはMFCのMDIが多く、最近はVCL（DelphiかC++ Builder）が多いね。
C++ Builderアイコンそのままのものを見たり、TStringGridマンマを見たり、みたいな。
999 ：
998：2008/08/12(火) 16:52:46
とｵﾓﾀが、今やインターネッツアプリの時代。
やっぱAJAX。
Pythonとかどーだろ。
よし、今から詳しく解説してみよう。
1001 ：
１００１：
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。