MFCに嫌気がさした人� ..
533:デフォルトの名無しさん
06/10/08 02:04:47
ｗｘＷｉｄｇｅｔｓに移ろうよ。
534:デフォルトの名無しさん
06/10/10 14:32:35
今酷い自演を見た
535:デフォルトの名無しさん
06/10/15 16:51:28
FOXに移ろう
536:デフォルトの名無しさん
06/10/27 04:45:24
つATL/WTL
537:デフォルトの名無しさん
06/10/29 02:51:41
PGやめようよ
538:デフォルトの名無しさん
06/10/29 05:31:43
PG(笑)
539:デフォルトの名無しさん
06/10/29 18:59:34
どうした？
PGがそんなに面白かったか？
540:デフォルトの名無しさん
06/10/29 19:35:21
反応したw
541:デフォルトの名無しさん
06/10/29 19:37:10
どうした？
反応がそんなに面白かったか？
542:デフォルトの名無しさん
06/10/29 19:45:22
かわいそうｗ
543:デフォルトの名無しさん
06/10/29 19:48:38
どうした？
かわいそうなのがそんなに面白かったか？
544:デフォルトの名無しさん
06/10/31 00:29:41
>>538-543 の幼稚なやり取りに嫌気がさした人の数↓
545:デフォルトの名無しさん
06/10/31 08:37:02
↑
おまいも用地
546:デフォルトの名無しさん
06/10/31 11:22:16
入れ食いw
547:デフォルトの名無しさん
06/11/08 13:31:59
URLﾘﾝｸ(www.kab-studio.biz)
MFCに移ったのですがあまりの設計の悪さに「Ｃプログラミング診断室」
(URLﾘﾝｸ(www.pro.or.jp))を初めて読んだとき以上の衝撃を受けました。
kabさんはMFCを結構押しているので申し訳ありませんがMFCは最悪のクラスライブラリです。
特にウィザードの吐き出すコードは正気を疑うものです。
548:デフォルトの名無しさん
06/11/08 13:42:31
なんだ尺八郎か
549:デフォルトの名無しさん
06/11/08 22:19:15
>>547
一貫性が無いって言うのは、確かにうなずけるな
最悪では無いと思うけど
550:デフォルトの名無しさん
06/11/09 08:40:02
>>549
最悪じゃないってことは、何よりマシってことよ？
551:デフォルトの名無しさん
06/11/14 00:02:47
だが、くそもっさりした.NETよりはぜんぜんよくないか？
C#は結局C++に挫折した奴が書くスクリプト言語でしょ
552:デフォルトの名無しさん
06/11/14 01:18:30
もっさりで、.NET Frameworkが必要なことに目をつぶることができるなら、
MFCより.NET Frameworkのクラスライブラリは大分まし。
553:デフォルトの名無しさん
06/11/14 08:37:19
世の中にはドトネトじゃないまともなクラスライブラリがあるわけだから、
Ｍ＄のダサダサ開発環境捨てるべきじゃね？
ネイティブ、ＣＯＭ、ドトネトの三つ巴の関係を考慮しながら開発なんて超変だお。
554:デフォルトの名無しさん
06/11/14 12:00:05
>>551
>C#は結局C++に挫折した奴が書くスクリプト言語でしょ
いや、実行時にコンパイルされるCモドキのVB。
555:デフォルトの名無しさん
06/11/14 12:17:19
じゃ、ドトネトは巨大なＶＢランタイムか。
556:デフォルトの名無しさん
06/11/14 12:22:08
C++に挫折するやつはC#も書けない気がするけどなｗ
557:デフォルトの名無しさん
06/11/14 13:07:10
>>555
VBのランタイムライブラリは
予めコンパイルされているだけ、まだまし。
558:デフォルトの名無しさん
06/11/14 16:56:40
.NET Frameworkのクラスライブラリはインストール時にngenをかけていると聞いたことがある。
559:デフォルトの名無しさん
06/11/16 01:27:47
使えればなんでもいいじゃん。
中の実装なんて、どうでもいいじゃん。
いやなら、VCL（古臭い）でも使ってろよ。
560:デフォルトの名無しさん
06/11/16 08:42:40
.NET Framework 2.0 廃止予定の API 一覧
URLﾘﾝｸ(www.microsoft.com)
（ <●><●>） ドトネト１．０～２．０廃止なのは分かってます
（Ｕ ）つ
ｕ ｕ
古臭いVCL ＞＞＞＞＞ ＷｉｎＦＸ ＞＞＞＞＞＞ ＭＦＣ
561:デフォルトの名無しさん
06/11/16 22:52:48
↑
使いにくさですよね？
562:デフォルトの名無しさん
06/11/17 15:38:27
>>561
URLﾘﾝｸ(www.google.co.jp)
MFC 汚い の検索結果 約 12,900 件中 1 - 10 件目 (0.03 秒)
563:デフォルトの名無しさん
06/11/17 20:44:36
URLﾘﾝｸ(www.google.co.jp)
MFC 綺麗 の検索結果 約 41,800 件中 1 - 30 件目 (0.21 秒)
564:デフォルトの名無しさん
06/11/17 20:51:39
URLﾘﾝｸ(www.google.co.jp)
MFC 美しい の検索結果 約 69,900 件中 1 - 10 件目 (0.04 秒)
565:デフォルトの名無しさん
06/11/17 21:29:53
URLﾘﾝｸ(images.google.co.jp)
AV女優 の検索結果 約 22,800 件中 1 - 20 件目 (0.32 秒)
566:デフォルトの名無しさん
06/11/17 22:12:13
MFCが汚いなんていってる人って結局C++が理解できていないんだよね
567:デフォルトの名無しさん
06/11/17 23:21:52
>>566
あの酷いコレクションクラス設計からしてマトモなAPIじゃないよ。
568:デフォルトの名無しさん
06/11/17 23:37:55
Doc-Viewアーキのカセ、むしろ更に、APPとFrameとDocとViewにはめられているRUNTIMEの鎖が汎用性にはネックになる部分で
慣れれば、用途によりけり抜け道と言うか、持って行き方があるけど。
自動生成のソースを全て底のクラスの意味まで理解すれば、色々応用が使えるようになってくる。
確かに特にRUNTIMEはマクロ、テンプレ、仮想関数(実行時まで型を決めずにおける)満載で、ウィンドウ用途に限って言うと、C++を存分に使い切っている。
マルチウィンドウ、例えば、ブラウザではサイトによりFormは無限だが、同様にTreeViewで開いたモノにより、画面を変えるなんてのにはMFCは最強。
.NETは使ったことは無いから分からないが、ActiveXはコンポーネントの中身が見えないのと同様のものを感ずるが、MFCはソースとしてフルに見れる、確かに大量にはあるが、元を辿るぶんには結構な量ではあるが、半端無いわけじゃない。
そして、ちまたにあるできあがったコントロールを使うなら、非常に楽にできる、できるようになるまでがたいへんだけど。
が、クライアント用途以外を考えるなら、WINDOWS以外も考えなければならないのでMFCじゃ無理。
569:デフォルトの名無しさん
06/11/17 23:46:44
Doc-Viewがカセ？
ポトペタ環境がありがたいと感じるのは最初だけ。
C#やVBはポトペタ環境がﾏｼﾞうぜー
570:デフォルトの名無しさん
06/11/17 23:54:53
My Favorite Class-library
571:デフォルトの名無しさん
06/11/17 23:59:02
>>569
例えば、
ファイルダイアログ＞開く・保存なんてのは、MFCじゃほんの数行でできるが(注:カセに則ってる分には)、
ファイルダイアログを開かずに直接、DATなりから自分が独自に作ったクラスにserialize使うなり、archive実装するとなると、最初はつまづくでしょ。
MFCの場合は、最初に壁があって、そこを超えると使いやすさが広大に開ける、そんなのが多い。
572:デフォルトの名無しさん
06/11/18 01:38:13
MFCの文句をいうならMFCで出来たものを使うなよ～～～～～～
573:デフォルトの名無しさん
06/11/18 02:27:18
.NETもReflectorでざっと読んでみたが糞設計だな・・・
574:デフォルトの名無しさん
06/11/18 12:22:57
Doc/Viewなんて、STLでDoc実装＋Ｖｉｅｗの描画にポトペタ部品の派生が最強。
結論：ポトペタ部品の派生が簡単なＶＣＬ最強。（ＤｅｌじゃなくてＢＣＢ）
575:デフォルトの名無しさん
06/11/20 09:35:40
ＭＦＣがOOPになってないところ羅列
・描画中にCBrushとか自分で生成破棄する必要がある。
576:デフォルトの名無しさん
06/11/20 09:37:42
それはOOPとは関係ないだろ
577:デフォルトの名無しさん
06/11/20 09:58:30
ウィンドウが自分を描画するブラシぐらい持つべきだろ。
持ってないならクラスにならん。
578:デフォルトの名無しさん
06/11/20 09:59:50
ＭＦＣがOOPになってないところ羅列
・ダイアログのリソースが１ファイルに収まるため、別プロジェクトがダイアログクラスを普通に共有できない
579:デフォルトの名無しさん
06/11/20 10:07:24
それはOOPとは関係ないだろ
580:デフォルトの名無しさん
06/11/20 10:23:38
CDialogクラス派生した部品が他プロジェクトの派生部品となりえない・・・ｱﾘｴﾅｽ
581:デフォルトの名無しさん
06/11/20 10:25:36
ＭＦＣがOOPになってないところ羅列
・ダイアログに貼る部品がActiveXであって、C++のclass宣言でクラス派生できない
582:デフォルトの名無しさん
06/11/20 10:28:53
それはOOPとは関係ないだろ
583:デフォルトの名無しさん
06/11/20 10:40:31
クラス派生できない→OOPではない
584:デフォルトの名無しさん
06/11/20 10:41:09
MFCはOOPとは関係ないだろ
585:デフォルトの名無しさん
06/11/23 22:21:16
つか、OOPとMFCは関係ない
586:デフォルトの名無しさん
06/11/23 22:27:14
はぁ？MFCにはOOPは関係ない
587:デフォルトの名無しさん
06/11/23 22:52:30
はぁ？OOPにはMFCは関係ない
588:デフォルトの名無しさん
06/11/23 22:59:37
もうちょっと変化に工夫を付けろ
589:デフォルトの名無しさん
06/11/23 23:36:15
はぁ？OPMにはCOFは関係ない
590:デフォルトの名無しさん
06/11/24 08:37:08
はぁ？KFCにはMACは関係ない
591:デフォルトの名無しさん
06/11/24 10:13:34
麻雀格闘倶楽部かと思った
592:デフォルトの名無しさん
06/11/26 19:54:07
あそこまで妙なマクロは使ってないけど、自作のC(not C++)のライブラリに似てて鬱だ>>MFC
593:デフォルトの名無しさん
06/11/28 17:17:55
ここは麻雀格闘スレですよ
594:デフォルトの名無しさん
06/11/28 22:22:52
そんな貴方にWide Studio
595:デフォルトの名無しさん
06/12/02 20:25:03
今後、.NETが浸透してネイティブアプリなんて必要なくなるのかな？
596:デフォルトの名無しさん
06/12/02 21:11:24
アプリケーションの必要性は使用されているライブラリやアーキテクチャには無い。
その有用性にあるのだ。
597:デフォルトの名無しさん
06/12/03 05:03:07
んなこと言ったらみもふたもない。
道具として何がよいかどうかの話なんでは。
598:デフォルトの名無しさん
06/12/03 05:33:58
漏れはもう、.NET/C#で事足りるなら、わざわざC++でネイティブアプリ作る気にはならないかも。
んで、実際大抵の用途には事足りる気がする。
599:デフォルトの名無しさん
06/12/03 07:19:52
ネイティブ実行ファイルが生成出来て
使いやすいC++のRAD開発環境があればいいけどね(M$製で)。
D言語 + RADでネイティブ吐く環境のがもっといいかも(やっぱM$製で)。
600:デフォルトの名無しさん
06/12/03 09:55:24
VC++とMFCでWinのプログラミングするのはほんと大変。
ある程度まともなアプリ書ける様になるまで3年かかった。
しかし未だ分からない事は山程あるので、まだまだ一人前とは言えないし。
601:デフォルトの名無しさん
06/12/03 13:01:16
MFCはウインドウのフレームだけでペインの中は自分でバリバリ書いてねってフレームワークだから、
RAD風にコントロールを並べてというのを期待するとCFormViewしかないので戸惑う。
C++ベースでRAD系の開発ツールはサードパーティにまかせて、あえてMSは出さなかったという話を
聞いたことがあるがソースが出てこない。BC++やVisual Age C++がそうだったのだろうか。
602:デフォルトの名無しさん
06/12/04 00:48:42
RADツールでもお客の要求などからコントロールを１から書くことが結構ある。
RADツールしかつかったことないひとはちょっとした変更でもできないなんていう。
たとえば、グリッドなんかでセルにボタンを配置してくれとか、コンボを配置してくれとか
簡単なのにできませんなんて・・・
603:デフォルトの名無しさん
06/12/04 00:59:27
そういえばMFCもけっこう使ったけど、CFormViewてほとんど使ったことないかもしれん。
604:デフォルトの名無しさん
06/12/04 01:06:39
ふつう使わない
605:デフォルトの名無しさん
06/12/04 02:14:46
Office2007はMFCなんでしょうか？
これからもパッケージソフトはC++でMFCなの？
C#とVBではプログラム作れるようになったけど、VC++でMFCもやっておいた方がいいんだろうか？
などと、学生は考えてしまいます
606:デフォルトの名無しさん
06/12/04 02:23:11
C#とVBは３日あれば覚えられる
607:デフォルトの名無しさん
06/12/04 02:27:49
事前にどういう言語知ってるかによるだろ
608:デフォルトの名無しさん
06/12/04 02:30:22
はぁ？
C/C++をしらない奴みたことないぞ
609:デフォルトの名無しさん
06/12/04 02:34:51
C#にはC/C++にない概念もあるだろ。
言語だけわかってもでっかいライブラリをある程度把握しないと何も出来きないし。
そういうのは他との対比ができれば理解が速いと思うけど。
VBは知らん。
610:デフォルトの名無しさん
06/12/04 13:22:21
すまん、VBでもmainから始めてた、偽装派遣で客先いくまで
611:デフォルトの名無しさん
06/12/06 19:46:56
どうでもいい
612:デフォルトの名無しさん
06/12/06 20:29:42
MFCかどうかはともかく、当分はC++の独占場だとは思う。
613:デフォルトの名無しさん
06/12/06 20:37:27
最近までVC6.0がメインで誰もC++を知らないC言語ワールドにいました。
614:デフォルトの名無しさん
06/12/06 21:07:20
>>613
Cだけ使ってる分にはVC6は軽くていいかもな
MSVCRT.DLLなら普通の環境にはデフォで入ってることが期待できるし
615:デフォルトの名無しさん
06/12/07 08:49:30
なんだかんだ言ってもいまだにVC6はインストールしてあるｗ
616:デフォルトの名無しさん
06/12/07 18:04:42
MFCってVC++2005でもサポートされるんだっけ？
MFCのメジャーバージョンうｐとかどうなんでしょ。
617:デフォルトの名無しさん
06/12/07 18:16:26
VC++ 2005 （Std以上）にはMFC 8が付いている。
618:デフォルトの名無しさん
06/12/07 18:26:04
＞MFC 8
VC++6のMFCと互換性おｋ？
619:デフォルトの名無しさん
06/12/15 00:54:53
俺はWEBアプリばかり作ってたから、未だにMFC未体験。
620:デフォルトの名無しさん
06/12/15 01:36:29
WEBとMFCになんの関係があるの？
621:デフォルトの名無しさん
06/12/15 01:55:01
どちらかというと、関係がないと言ってるように見えるのだが。
622:デフォルトの名無しさん
06/12/18 14:09:11
Ｖ＄ドトネトに逝行してもＭＦＣ使ってる人っています？
逝行の致命的な問題とか無いでつか？
623:デフォルトの名無しさん
06/12/19 11:17:23
＞CDialog１つに対してresource.hとrcファイルがあって、
＞プロジェクトをダイアログ単位の部品クラスに分割できれば、
＞まだ使えたようなｷｶﾞｽﾙ
他のプロジェクトにダイアログをカレントプロジェクトにコピペといった使い方しかできないおね。
ＭＦＣのパワーユーザーとか、他のプロジェクトのダイアログをクラスライブラリとして使いまわせない事をどう思ってんだろ？
624:デフォルトの名無しさん
06/12/19 11:24:20
コモンダイアログ
625:デフォルトの名無しさん
06/12/19 11:28:58
＞コモンダイアログ
ＭＦＣではない。
626:デフォルトの名無しさん
06/12/19 12:12:14
ダイアログテンプレート
627:デフォルトの名無しさん
06/12/19 12:18:12
Vi$taでもMFC使い続けますか？ドトネトにコンバートしますか？
628:デフォルトの名無しさん
06/12/19 12:43:53
>>623
ダイアログのリソース関連はまったく同意だなぁ
新しいプロジェクトはDLL化して分割管理しているからまだマシだけど
ずっとメンテナンスしてるプロジェクトがダイアログリソースだけでが２５０くらいあって
もうどうしようも無い感じなってきてる
629:デフォルトの名無しさん
06/12/19 13:20:11
ダイアログリソースって壊れやすいから嫌い。
変なマクロもぶちまけるし。
ソースとリソースを相互変換するツール作ればいいだけじゃ？
630:デフォルトの名無しさん
06/12/19 13:49:19
＞ソースとリソースを相互変換するツール作ればいいだけじゃ？
つ BCBなら１ダイアログが３ファイル（.h/.cpp/.dfm）
631:デフォルトの名無しさん
06/12/19 13:52:19
ダイアログテンプレート
632:デフォルトの名無しさん
06/12/22 02:38:35
厨な質問だと重々承知しておりますが質問します。
WindowsオンリーであればＭＦＣ使った方がいいですかね？
世間の評価が気になるのですけど、ＭＦＣ？：( ´,_ゝ`)ﾌﾟｯてな感じになりませんか？
633:デフォルトの名無しさん
06/12/22 07:38:32
>>632
お好きなように。
>ＭＦＣ？：( ´,_ゝ`)ﾌﾟｯてな感じになりませんか？
MFC でも何でも、マトモなものが作れてるなら問題ない。
634:デフォルトの名無しさん
06/12/22 08:46:43
C/C++プログラマへアドバイス
URLﾘﾝｸ(www.01-tec.com)
（個人的にはＭＦＣは VC++ の唯一の汚点だとも思っています^^;）ので、Windows系のプログラムを作るならこれ↓
635:デフォルトの名無しさん
06/12/22 09:01:25
いや・・・さすがにMFCとSTLを同列で扱ってたりするような糞サイトは参考にならんと思うが・・・
636:デフォルトの名無しさん
06/12/22 09:10:27
＞MFCとSTL
MFCのCStringとstd::string問題を扱ってるだろ。
635=その問題を知らないとはC++使ってるとは言えない。
637:デフォルトの名無しさん
06/12/22 09:10:45
パソコンだって箱より中身の方が大事なわけだし
それがわかってれば箱なんか気にしない
638:デフォルトの名無しさん
06/12/22 09:12:10
URLﾘﾝｸ(program.station.ez-net.jp)
□ Visual C++ の互換性…
Visual Studio .NET を買って早数日…。
COM コンポーネントのバージョンアップを図るべく Visual C++ 7.0 にて ATL COM のプロジェクトをコンパイルしなおすことになりました。
□ MFC 7.0 と ATL 7.0
□ 変更点の補足
□ エラーを取り除く…
□ COM 動かず…
639:デフォルトの名無しさん
06/12/22 09:13:29
意味わかんないです（＞＜）
URLﾘﾝｸ(www.microsoft.com)
System.Windows.Forms.Form
ApplyAutoScaling()
メッセージ : このメソッドは非推奨になりました。
代わりに、ApplyAutoScaling メソッドを使用してください。
.NET Framework 2.0 廃止予定の API 一覧
URLﾘﾝｸ(www.microsoft.com)
（ <●><●>） ドトネト１．０～２．０廃止なのは分かってます
（Ｕ ）つ
ｕ ｕ
640:デフォルトの名無しさん
06/12/22 09:24:10
>>636
std::stringはSTLじゃないよ。
641:デフォルトの名無しさん
06/12/22 09:30:03
MFCもSTLもstringもC++のライブラリ。
同列に並べずどうする？
642:デフォルトの名無しさん
06/12/22 09:41:51
Windowsプログラミングを行うためのライブラリであるMFCと
標準ライブラリを同列に並べるの？libgnomeとlibcぐらい違うでしょ。
MFCのごく一部がC++標準ライブラリと被ってるのは確かだ。
だからMFCのコンテナを使うくらいならSTLのコンテナを使いましょうと言うならまだ分る。
要はMFC全体は標準ライブラリと排他的に選ぶものではないということ。
643:デフォルトの名無しさん
06/12/22 10:02:05
サイトには、
＞MFC はＣ＋＋のお手本として良い題材とは思いません。STL の勉強をお薦めします。
と書いてあるから、排他してなくて、勉強時にはMFCとSTL比べたらSTLを選べと言ってる。
＞要はMFC全体は標準ライブラリと排他的に選ぶものではないということ。
おまいのいいがかりじゃん。
644:デフォルトの名無しさん
06/12/22 10:17:32
よく読めよ。MFCを勉強するかSTLを勉強するかではなく、
C++を勉強する時に使うべきはSTLかMFCかとおっしゃってるわけだが。
645:デフォルトの名無しさん
06/12/22 10:21:02
＞C++を勉強する時に使うべきはSTLかMFC
C++を勉強するときに、STLとMFCと選ぶという行為は変じゃない。
その場合のSTLの選択も正しい。
で？
646:デフォルトの名無しさん
06/12/22 10:22:21
＞STLとMFCと選ぶという
あ、ゴメンあいまいに書いちゃった。
C++勉強しよう。STLを勉強しようかな、MFCを勉強しようかな、という同列に並べた選択は変じゃない。
ごくふつー。
647:デフォルトの名無しさん
06/12/22 10:28:15
まぁ、MFC使って、
AppWizardの吐き出したコードの汚さに目が点、
画面に使えるコントロールが少ない、
それでも画面を何とかするにはActiveX使うしかない、
という流れでどうせ頓挫するさ。
という意味では、一旦MFC漬かってみれば結論でるお。
648:デフォルトの名無しさん
06/12/22 10:44:40
> C++勉強しよう。STLを勉強しようかな、MFCを勉強しようかな
作れるものが全然違うから同列に出来ないと俺は思ってる。
何かを作るのが目的でC++を勉強するってのが俺のスタンスだからだろうけど。
MFCを使ったコンソールアプリを作るのがMFCの勉強とは思えない。
堂々巡りでスレ汚しになる予感だ。
ケチ付けた方からで悪いが、この件はMFCの糞さとは関係ないからここら辺にしておこう。
649:デフォルトの名無しさん
06/12/22 12:39:33
＞作れるものが全然違うから同列に出来ないと俺は思ってる。
「作るものが～」という文脈は、作るのが目的の場合。
勉強する場合作るものはある程度何でも良くて、C++文法やクラスライブラリ構造の１例理解がターゲットだったりするわけ。
650:デフォルトの名無しさん
06/12/22 16:29:04
もうObjective-CとCocoaに移行すればいいじゃん。
そうすれば糞面倒なC++とMFCにもおさらば。
651:デフォルトの名無しさん
06/12/22 17:11:43
C++が面倒（やっぱ、慣れるまではちょっと面倒）なんじゃなくて、MFCが面倒。
それから、C/C++系ライブラリは必要、MFCは必須ではない。
652:デフォルトの名無しさん
06/12/22 20:38:30
一度でいいから見てみたい。
MFCを使わずにC++とWin32APIで
クラスの概念の存在意義を見いだせる書き方をされたコード。
653:デフォルトの名無しさん
06/12/22 21:02:05
ATL/WTLはどうですか？
654:デフォルトの名無しさん
06/12/25 08:47:03
＞MFCを使わずにC++とWin32APIで
C言語とC関数ライブラリでひとかたまりのように、
C++とクラスライブラリで一セット。
分離はできない。
MFCを別のクラスライブラリに差し替えるのが正しい。
655:デフォルトの名無しさん
06/12/25 11:34:32
小物を沢山作る人なんかは自分で小さいクラスライブラリを作ってる事もあるね。
漏れも昔はやってた。
656:デフォルトの名無しさん
06/12/26 04:41:55
サードパーティの有料コンポーネント使った方が速いというか
657:デフォルトの名無しさん
06/12/26 20:37:28
サードパーティの有料コンポーネントってびみょーなのが多い
なんだこの程度のコンポーネントで売り物になるんだと思うことがほとんど。
自作したほうが、早い
658:デフォルトの名無しさん
06/12/26 23:26:33
wcはcの入門書の例題によく出てくるから、まあ範疇でいいじゃない。
wc sed grep lsなど簡単なunixコマンドは大抵win32版がgnuその他のフリーウェアで
転がっているから、ググレば拾えるよ。
659:デフォルトの名無しさん
06/12/26 23:27:22
>>658
やや、誤爆った。スマソ。
660:デフォルトの名無しさん
06/12/27 09:16:40
今ってネットにフリーのクラスライブラリのソースそのまんまのコンポーネントが溢れてる時代だよね。
ＭＦＣはマジでその辺が無い。
661:デフォルトの名無しさん
06/12/27 09:20:26
漏れはCodeProjectでさんざん世話になったが・・・
662:デフォルトの名無しさん
07/01/03 15:22:16
ほっしゅ
663:本田
07/01/03 19:07:29
>>652
URLﾘﾝｸ(owlnext.sourceforge.net)
664:デフォルトの名無しさん
07/01/12 10:24:15
＞永久プログラマー
＞URLﾘﾝｸ(www.est.co.jp)
マイクロソフトC/C++7.0とクラスライブラリMFC1.0を使って、アプリケーションを作り始めた。
半分ほどプログラミングした時点でVisualC++1.0が米国で出荷された。
その開発環境の良さやMFC2.0の高級な機能に刺激されて、VC++に開発環境を移行した。
MFC1.0は、Win16APIにクラスライブラリの皮を被せただけの簡単なものである。
彼はこの上に、独自の高級なクラス構築していたのだが、MFC2.0が見事にそれを葬ってくれた。
MFC2.0に合わせて、モジュール構造から作り直すのに6ヵ月ほどを費やした。
665:デフォルトの名無しさん
07/01/13 13:25:12
>>664
＞久遠のプログラマー
マイクロソフトC/C++7.0はMFCなどの分厚いマニュアルが何冊も付いてきて、
パッケージの幅が５０ｃｍはあったと思う。
これを抱えたまま秋葉原駅の階段で転倒。腕の骨を骨折するに至った。
666:デフォルトの名無しさん
07/01/14 02:10:59
ワロタ
667:デフォルトの名無しさん
07/01/14 03:28:18
>>660
CodeGuru
668:デフォルトの名無しさん
07/02/09 11:54:29
Vi$taでもMFC使える？
669:デフォルトの名無しさん
07/02/09 19:31:51
>668
おいしい情報を教えるよ。
僕が開発した、「馬鹿には見えないMFC」を使えば、Vistaでもツルツル動くよ。
格安で譲って上げるから、レスちょうだい。
670:デフォルトの名無しさん
07/02/09 20:50:33
ツルツルａｇe
671:デフォルトの名無しさん
07/02/10 10:00:05
メモリーフローコントロール
672:デフォルトの名無しさん
07/03/21 03:27:23
>>665
VisualC++1.0の紙マニュアル付きを思い出す
あれ買って帰った人いるのかなぁ
673:デフォルトの名無しさん
07/04/01 18:21:49
あげあげ
674:デフォルトの名無しさん
07/05/02 11:35:58
MFCに四苦八苦しながらもようやくまともにアプリ書けるようになったと思ったら
.NETにWin64APIですか…orz
675:デフォルトの名無しさん
07/05/02 15:15:49
>>674
MFCよりゃ癖もなくて楽だと思うけどね。
676:デフォルトの名無しさん
07/05/05 23:08:13
MFCにかわるものはあるんですか？
（個人的にMFCは嫌いじゃない）
677:デフォルトの名無しさん
07/05/05 23:09:23
MFCの様にやりたいなら、MFCが一番だろｗ
678:デフォルトの名無しさん
07/05/08 10:40:50
MFC（GUIイマイチ） + VCL（某製） → .NET（モッサリ）
679:デフォルトの名無しさん
07/05/11 20:43:21
まぁ所詮「イジワルC++」ですから。
680:デフォルトの名無しさん
07/05/12 00:07:23
なんか、OrcasだとMFCも Vista対応されるんだな。
681:デフォルトの名無しさん
07/05/12 18:26:10
mfcはそこそこosに近い所で動きながらそこそこラクができるのが
いいんじゃないの。CWndベースで何でも作れるやん。
682:デフォルトの名無しさん
07/05/13 15:52:29
あれだなんだっけ？
メモリデバイスコンテキストとかセレクトオブジェクトで取得したもんを
開放したり確保したりかってにやってくれるのがいい
アレ、自分でやると開放していいのか悪いのかさっぱりわからん
あと、トラッカークラスとかいいｗ
683:デフォルトの名無しさん
07/05/14 09:36:10
＞CWndベース
このクラス、Win32APIがくっついてるだけで、
変数も内部に保持しないわ、
楽にしてくれるメソッドは無いわ、
超スペシャルカス設計。
684:デフォルトの名無しさん
07/05/14 11:03:01
もともと、単なるラッパーとして設計されたクラスだもの。
685:デフォルトの名無しさん
07/05/14 11:28:42
＞単なるラッパー
いや、単なるラッパーでも内部に変数保持する筈だし、
便利なメソッドが付いてる筈。
㌧ﾃﾞﾓキチガイ設計だお。
686:デフォルトの名無しさん
07/05/14 12:50:59
MFCのステートのカオス度は異常
687:デフォルトの名無しさん
07/05/14 16:51:56
え？何を内部に変数保存するの？
688:デフォルトの名無しさん
07/05/14 16:55:12
よくわかんねーけどインスタンスだろ
689:デフォルトの名無しさん
07/05/14 17:02:42
CPenとか内部に保持してくれたりリリースしてくれたりしないのは変杉。
690:デフォルトの名無しさん
07/05/14 17:33:30
設計当時、GDI上のハンドルは全てキャッシュだからなぁ。
Win16/Win95時代の設計なんだよ。
だから、どうしても変な実装になる。
691:デフォルトの名無しさん
07/05/14 17:43:37
VCLならちゃんとした設計になってるよ。
各コントロールやウィンドウがCanvasっていう抽象クラスを持ってて、
Canvasクラスがペンやメソッド持ってるお。
692:デフォルトの名無しさん
07/05/15 09:09:01
apiを直に使うのに慣れてたら違和感ないだろう
apiとやり方が全然違うとかえって使いにくいし
693:デフォルトの名無しさん
07/05/15 09:17:47
＞apiを直に使うのに慣れてたら違和感ないだろう
違和感ありあり。
apiの機能を端折ることなくメソッド追加できるのが、クラスベース言語＆クラスライブラリ。
クラスライブラリが無ければ、apiのラップ自体が開発となるのに、
目の前にトンでも設計便利なところ無しクラスライブラリを目の前に置かれると目が点。
694:デフォルトの名無しさん
07/05/15 13:23:55
>691
その実装も問題ありだな。
つーか、OS/2だと、DCとPSって分けられてたって知ってる?
695:デフォルトの名無しさん
07/05/15 13:27:13
何がどう問題なのか書かなきゃ意味無し。
696:デフォルトの名無しさん
07/05/15 15:01:06
ほう、ドリキャスとプレステで分けられてたのか。
三千院家の屋敷みたいだな。
697:デフォルトの名無しさん
07/05/20 12:21:41
たまにはWFCのことも思い出してあげてください…
698:デフォルトの名無しさん
07/05/22 23:20:30
ちゃんとしたものが作れるのであれば、なんでもいいよ。
MFCだろうとVCLだろうと。
699:デフォルトの名無しさん
07/05/23 00:49:16
WTL最強
700:デフォルトの名無しさん
07/05/23 13:30:19
URLﾘﾝｸ(www.net3-tv.net)
701:デフォルトの名無しさん
07/05/29 14:45:22
MFCで0xc0000135
URLﾘﾝｸ(forums.microsoft.com)
702:デフォルトの名無しさん
07/06/21 16:15:40
URLﾘﾝｸ(itpro.nikkeibp.co.jp)
1990年代の中頃になると，主にCプログラマを対象とする，
比較的難易度の高いMicrosoftの「Win32 API」が，
さらに難解な「Microsoft Foundation Classes (MFC)」と「ActiveX Template Library (ATL)」に取って代わられた。
これら2つのC++フレームワークは，控えめに言っても，コンピュータ・サイエンスの歴史上最悪の出来事に含まれる。
703:デフォルトの名無しさん
07/06/21 20:24:08
えー、歴史を知ってる人はそんなに簡単に史上最悪とか言わないよー。
だって、必用があったから拡張されて複雑になるわけで、それなりの理由があるんだから。
704:デフォルトの名無しさん
07/06/21 22:15:44
こいつ只のMSアンチだろｗ
705:デフォルトの名無しさん
07/06/22 08:36:53
＞必用があったから拡張されて複雑になるわけで
MFCに関しては当初から複雑。
GUIに関してはプロジェクトを超えて使いまわし出来ない。
706:デフォルトの名無しさん
07/06/22 09:53:55
>>705
>GUIに関してはプロジェクトを超えて使いまわし出来ない。
まさか、リソースIDに整数使ってたりする？
707:デフォルトの名無しさん
07/06/22 10:13:58
そういう問題じゃなくて、
resource.hの存在自体がoop的にはトンでもキティなの。
708:デフォルトの名無しさん
07/06/22 23:25:25
歴史的にリソースは CのSDKからそのまま持ってきたんだから、oop的にキモいのは当たり前なんだよな。
MFCが当初から複雑って、16bit時代のMFCの事を指してる?
当初は簡単なモノだったさ。
709:デフォルトの名無しさん
07/06/25 08:38:39
＞MFCが当初から複雑って、16bit時代のMFCの事を指してる?
いや、今現在のヤツのダイアログ作成が超サイアク。
710:デフォルトの名無しさん
07/06/25 12:34:53
>709
最初のバージョンから比べると、今のダイアログ作成はかなり楽になった方だと思うけど。
最初のバージョンは、SDKのダイアログエディターしかなかったんだぜ。
711:デフォルトの名無しさん
07/06/25 13:01:47
＞最初のバージョンから比べると、今のダイアログ作成はかなり楽になった方だと思うけど。
その比較に何の意味がある。
＞最初のバージョンは、SDKのダイアログエディターしかなかったんだぜ。
ｲﾗﾈ
712:デフォルトの名無しさん
07/06/26 22:33:20
711は昔から常駐してるクソだから放置しとけ
713:デフォルトの名無しさん
07/06/27 21:25:03
歴史を知ってれば…って話前提なんだから、最初のバージョンの比較に意味はあるだろ。
このバカ。
714:デフォルトの名無しさん
07/06/28 09:05:57
現状がサイアクなのに、
＞最初のバージョンから比べると、今のダイアログ作成はかなり楽になった方だと思うけど。
といった内容に何の意味がある。
このバカ。
715:デフォルトの名無しさん
07/06/28 14:15:10
> GUIに関してはプロジェクトを超えて使いまわし出来ない。
MFCベースで作成した拡張DLLで、複数のプロジェクトでGUIを共有
してますが、何か？
716:デフォルトの名無しさん
07/06/28 14:47:18
あの、それDLLの共有。
OOPでいうところの、ベースダイアログと派生ダイアログっていう共有じゃないでしょ。
ちょっと処理が違うダイアログ作ろうと思って、DLL変えてるようじゃoopじゃないから。
派生クラスを増やしても他の派生クラスのバグの元とならないことが重要。
717:715
07/06/28 15:30:10
>>716
> OOPでいうところの、ベースダイアログと派生ダイアログっていう
> 共有じゃないでしょ。
それをやりたけりゃ、作成した独自ダイアログクラスを持つDLLから、
さらに別の拡張DLLなりアプリケーション側なりで、派生ダイアログ
クラスを定義すればいいだけでしょ？
そのやり方も知らないで、よくプログラマやってられるな～。それとも
口先だけの自称システムエンジニア様か、自称ITコンサル様？(w
> 派生クラスを増やしても他の派生クラスのバグの元とならないことが重要。
そんなもんクラス設計する側に依存する問題であって、MFCに依存の
問題じゃねぇだろが。
いるんだよな～。オープン厨房とか、自分のスキルや知識のなさを棚に
上げて、何か問題を起こすとWindowsやらMFCのせいにして、ひたすら
Unixの営業を始める香具師。
718:デフォルトの名無しさん
07/06/28 15:41:49
＞それをやりたけりゃ、作成した独自ダイアログクラスを持つDLLから、
＞さらに別の拡張DLLなりアプリケーション側なりで、派生ダイアログ
＞クラスを定義すればいいだけでしょ？
これって派生したダイアログ側でVC++のGUIでコントロール足せんやん。
出来ないことを出来るように書くな。
719:デフォルトの名無しさん
07/06/28 17:28:02
>>718
>これって派生したダイアログ側でVC++のGUIでコントロール足せんやん。
無茶しようとしてできなかったからMFC糞、という結論になったんですか。
720:デフォルトの名無しさん
07/06/28 17:33:49
>>719
いや、MFC以外では出来るんだけど。
721:デフォルトの名無しさん
07/06/28 18:20:16
>>720
>>MFC以外
kwsk
722:715
07/06/28 18:28:34
> これって派生したダイアログ側でVC++のGUIでコントロール足せんやん。
> 出来ないことを出来るように書くな。
無知とは、ホント恥ずかしいな。
723:デフォルトの名無しさん
07/06/28 21:45:11
何でこのスレの住人はこんなにも攻撃的なのだろうか。
MFCの有用性よりもそっちの方が気になる。
724:715
07/06/28 21:53:13
クリエイターはＳ。(by 江川達也)
725:デフォルトの名無しさん
07/06/28 22:53:17
口先だけの自称ITコンサル様の俺が来ましたよ。モットーは生かさず殺さず。
726:デフォルトの名無しさん
07/06/29 00:29:29
さすがに、現状が最悪とか言って、くそみそ一緒にされてもな。
つーか、技術者のどこがクリエイター?
727:デフォルトの名無しさん
07/06/29 08:39:32
MFCってM$社内でさえ使われないくらい悪いものじゃん。
その後のWTLと共にアナウンスではメジャーバージョンうｐ停止。
実際にはうｐされたけどさ。
しかしだ、ドトネトに逝こう汁とは、いかがなものかと。
728:デフォルトの名無しさん
07/06/29 11:18:19
C++/CLIも最悪だしねぇ。C#は体感遅いし。
結局、C++と .Netは層を分けて設計するのがベストかねぇ。
729:デフォルトの名無しさん
07/06/29 11:30:55
ドトネトは使わないのが正解らしい：
＞URLﾘﾝｸ(capsctrl.que.jp)
実はマイクロソフトにとってはすでに「来年」が過ぎている。
我たちはマイクロソフトのプロジェクトに対する顧客（特にアメリカの顧客）の関心が著しく減少しているのに気づいた。
オーストラリアでは、.NETは顧客の地盤をまったく得られなかった。
このデータから何を受け取ればいいのかはよく分からない。
730:デフォルトの名無しさん
07/06/29 12:00:17
>>722
プログラムから追加するだけなら出来て当たり前なんだから、
>>718 はもっと凄いことを要求してんじゃね？
「基底クラスのデザインがダイアログエディタで編集できないじゃねーか！」
とかさ。
731:デフォルトの名無しさん
07/06/29 12:05:58
＞「基底クラスのデザインがダイアログエディタで編集できないじゃねーか！」
これって、C++Builderだとふつーに出来るじゃん。
メソッドのオーバーライドは当たり前として、イベントハンドラのオーバーライドも出来るお。
732:722
07/06/29 12:14:39
>>730
その可能性は考えた。けど、>>718 と同一人物かどうか判らんけど
>>720 では ...
> いや、MFC以外では出来るんだけど。
とハッキリ書いてるし、きっと違うんじゃないか？(w
> 「基底クラスのデザインがダイアログエディタで編集できないじゃねーか！」
だと、MFCに限らず、C++でダイアログリソース使うケースは全て該当する
ので、 >>720 と明らかに矛盾する。
ただし、プログラムでダイアログリソースを動的に生成してオブジェクト
作成時に、コンストラクタやCDialog::Create()に渡す仕掛けを自前で
提供すれば、MFCのCDialogクラスでも、できなくもない気がする。
いずれにしろ、継承されたリソースを記述したり、編集したりできない
のは、リソースエディタの仕様やデータ構造の問題でMFCとは無関係だろう。
733:デフォルトの名無しさん
07/06/29 12:19:07
＞だと、MFCに限らず、C++でダイアログリソース使うケースは全て該当する
誰がどう見てもMFCのダイアログエディタがサイアクだろ。
734:デフォルトの名無しさん
07/06/29 12:32:09
>>733
>MFCのダイアログエディタ
735:デフォルトの名無しさん
07/06/29 13:03:21
734=あれがMFCと連動したMFC専用だという事を知らないMFC井の中の蛙
736:722
07/06/29 13:41:27
思うに、>>735 は、VBプログラマか、C++ Builderあたりでも使っていた
のだろうか？おそらく使いこなせていなかったと想像できるが。
少なくとも、リソースエディタが、MFC専用ではないことすら知らない
ようだ。そして、世の中には継承を記述できるリソースエディタが存在
するらしい。そんなモン見たことないけど。
737:734
07/06/29 13:47:06
CreateDialogIndirect や CreateDialogParam ってのは API だと思っていたが
いやはや、MFC と連動しているとは知らなかった。
738:デフォルトの名無しさん
07/06/29 13:52:53
734=ゆとりMFC世代のM$脳
739:デフォルトの名無しさん
07/06/29 13:54:09
＞少なくとも、リソースエディタが、MFC専用ではないことすら知らない
DDX埋め込むからパーフェクトにMFC専用だよ。
722=ウソが平気
740:デフォルトの名無しさん
07/06/29 14:54:18
ああ、クラスウィザードと混同してんのか。間抜けだなあ。
741:722
07/06/29 14:56:57
DDX埋め込む？ハァ？もしかして、DDX_Control()とか、DDX_Text()とか
のことか？ あれを自動でソースに埋め込んでいるのは、クラスウィ
ザードなわけで、リソースエディタではないわけだが？
きょうび、こんなヤツがプロジェクト仕切ってたりした日にゃ、どんな
簡単なプログラムさえリリースされることはあるまい。
742:デフォルトの名無しさん
07/06/29 15:17:42
歴史を知らないヤツほど、最悪という。
743:デフォルトの名無しさん
07/06/29 15:23:08
リソースエディタとクラスウィザード込みだから、
MFCのダイアログエディタと逝ってるだろうが。
それを勝手にミスリード：
＞MFCのダイアログエディタ
＞少なくとも、リソースエディタが、MFC専用ではないことすら知らない
こういう感じ。
間抜けだなあ。 ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
744:デフォルトの名無しさん
07/06/29 15:29:25
絶対揺るがない結論：
MFCのダイアログエディタ（リソースエディタ、クラスウィザード）は、
何をどう言い訳しても、超使い難い。
745:722
07/06/29 15:35:05
>>743
統合環境では、MFCを使わないWin32 APIのみによるプロジェクトも作成
可能なわけだが、そのプロジェクト内でリソース編集には、リソースエデ
ィタを使わないのかぃ？(w
それに、MFC使っていようが、MFC使っていまいが、リソースのソースファ
イルの中身はテキストなので、普通にメモ帳とかで編集できるわけで、
おそらくそれさえも知らないのだろうな。
ここまで無知っぷりを晒すとは。貴重な反面教師として絶滅危惧種に指定
すべきだな。
ところで、MFC以外なら継承を記述できるという例を早く挙げてくれよ。
746:デフォルトの名無しさん
07/06/29 15:38:00
＞統合環境では、MFCを使わないWin32 APIのみによるプロジェクトも作成可能なわけだが、
＞そのプロジェクト内でリソース編集には、リソースエディタを使わないのかぃ？(w
＞MFC使っていようが、MFC使っていまいが、リソースのソースファイルの中身は
＞テキストなので、普通にメモ帳とかで編集できるわけで、
↑
これが、”何をどう言い訳しても”っていう中身ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
２回も同じことを書いて必死ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
やっぱり絶対揺るがない結論：
MFCのダイアログエディタ（リソースエディタ、クラスウィザード）は、
何をどう言い訳しても、超使い難い。
747:デフォルトの名無しさん
07/06/29 15:48:46
_, ._
（ ・ω・） 芝刈り機出動
○=｛=｝〇,
|:::::::::＼, ', ´
.ｗｗし ｗ`（.＠）ｗｗｗｗ
748:デフォルトの名無しさん
07/06/29 15:52:39
芝刈ってみました：
やっぱ、リソースエディタ形式を守るため、というのはいい訳だと思うんですよ。
なぜなら、MFCダイアログエディタでコントロール貼り付けたものをC言語で利用するかっていうと、そんな事やりません。
それよりも、GUIエディタ＋クラスライブラリでペタペタ貼り付けて、かつ、ジェネレートされるコードが少ない、ってのが一番。
749:デフォルトの名無しさん
07/06/29 15:53:30
ゆとりが一匹暴れてるのか
750:722
07/06/29 16:08:52
ゆとりというより、キチガイだろう。
751:722
07/06/29 16:17:19
> MFCダイアログエディタでコントロール貼り付けたものをC言語で利用するかっていうと、そんな事やりません。
こんなことを平気で書くくらいだから、そもそもMFCを使わず、C言語(API)
だけでダイアログを出す方法も知らないし、当然コードすら書けないんだろ
うな。
MFC自体は、マイクロソフト謹製という点を除けば、C++で書かれたクラス
ライブラリの1つに過ぎないし、完全なソースも付いていて、C++の基本が
正しく理解できてさえいれば、さほど悩むことはない。
752:デフォルトの名無しさん
07/06/29 16:21:47
＞> MFCダイアログエディタでコントロール貼り付けたものをC言語で利用するかっていうと、そんな事やりません。
＞こんなことを平気で書くくらいだから、そもそもMFCを使わず、C言語(API)
＞だけでダイアログを出す方法も知らないし、当然コードすら書けないんだろうな。
クラスライブラリを使う人間がC言語を使わない、というのは妥当な発言。
それに対して”こんなことを平気で書くくらいだから”なんて、これは言い掛かりがハゲし杉る。
こういうの”ゆとり”、”キチガイ”というのだろうか。
文脈に関係なけど、VC++1.0以前のMSC＆コマンドプロンプトででWin16アプリを作る時代から開発してまつ。
753:デフォルトの名無しさん
07/06/29 16:28:06
＞絶対揺るがない結論： MFCのダイアログエディタ（リソースエディタ、クラスウィザード）は、 何をどう言い訳しても、超使い難い。
こう書いているのに、
リソース形式の言い訳ばっかり（３回目ｗ）書いた上に、
＞MFC自体は、マイクロソフト謹製という点を除けば、C++で書かれたクラス
＞ライブラリの1つに過ぎないし、完全なソースも付いていて、C++の基本が
＞正しく理解できてさえいれば、さほど悩むことはない。
こういう文脈から外れた自分が上に立つための関係ないこと書き出して、イヤなヤツ杉る。
754:デフォルトの名無しさん
07/06/29 16:30:36
結論２：
MFCを使うとリソースの言い訳ばかりせざるを得ない。
嫌なヤツになる。
755:722
07/06/29 16:40:52
> 文脈に関係なけど、VC++1.0以前のMSC＆コマンドプロンプトででWin16アプリを作る時代から開発してまつ。
それが、何か？ 漏れはCP/M-80の時代からプログラムやってるよ。
MFCのリソースエディタが嫌なら、CWndから全部自前でコントロールクラス
を作成し、XML形式でも何でも好きなフォーマットのリソース形式を自前
で定義して、それ用のGUIエディタでも何でも、好きに作ればよいだけ。
VBとか、まさにそんなもんだろ。
>>752-753 には一生掛かっても無理だろうけどナー。
MFC自体もマイクロソフトも、MFCを使うことを強制してはいない。
ところで、MFC以外なら継承を記述できるという例を早く挙げてくれよ。
756:デフォルトの名無しさん
07/06/29 16:43:48
＞>>そもそもMFCを使わず、C言語(API) だけでダイアログを出す方法も知らないし、当然コードすら書けないんだろ うな。
＞> 文脈に関係なけど、VC++1.0以前のMSC＆コマンドプロンプトででWin16アプリを作る時代から開発してまつ。
＞それが、何か？ 漏れはCP/M-80の時代からプログラムやってるよ。
この文脈に流れないように釘打っといたのに流れるヴぁかなヤシ。
＞MFCのリソースエディタが嫌なら、CWndから全部自前でコントロールクラス
＞を作成し、XML形式でも何でも好きなフォーマットのリソース形式を自前
＞で定義して、それ用のGUIエディタでも何でも、好きに作ればよいだけ。
＞VBとか、まさにそんなもんだろ。
氏滅したブビを出すなんてヴぁかなヤシｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
お前が知ってる世界はだっせー
757:デフォルトの名無しさん
07/06/29 16:45:17
＞MFC自体もマイクロソフトも、MFCを使うことを強制してはいない。
当たり前だろ、M＄社内でMFCなんてきちゃないもの使ってないよｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
お前はMFC使ってれば良いんだよｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
758:デフォルトの名無しさん
07/06/29 17:05:44
継承ﾏﾀﾞｰ？（AAｒｙ
759:デフォルトの名無しさん
07/06/29 17:06:07
再度指摘。
>MFCのダイアログエディタ
760:722
07/06/29 17:07:07
君の言うＭ＄って、ＭＳＫＫのことか？
まぁ、あそこはＭＳ内部でも極めて特殊で、代理店統括みたいなコトしか
やってないから。ＭＳＫＫで過去に開発した製品って、はがきスタジオ
くらいだろ。実態は、偽装請負だけど。(w
MSDNも別会社に丸投げしてるしな。
MFCはアップデートされないんじゃなくて、既に出来上がってる部分は
バグが枯れているんだよ。それに、MFC使ってる香具師は、自前の派生
クラスライブラリくらい構築していると思われ。
761:デフォルトの名無しさん
07/06/29 17:38:11
＞再度指摘。
＞>MFCのダイアログエディタ
MFCのダイアログエディタ＝リソースエディタ＋クラスウィザード
＞君の言うＭ＄って、ＭＳＫＫのことか？
”君”ってｴﾗｿｰだね。
違う。本社。
＞継承ﾏﾀﾞｰ？（AAｒｙ
教えると損だから教えないことにした。
762:デフォルトの名無しさん
07/06/29 18:13:57
ダイアログエディタはクラスウィザードじゃねぇよ。馬鹿なんじゃないの?
763:デフォルトの名無しさん
07/06/29 18:18:06
少なくともこのスレでは、お前以外にMFCのダイアログエディタという言葉を使う奴はいないし、
そのように考える思考も持っていない。あくまでリソースエディタとクラスウィザードは、
（連携はするが）別の機能と捉えているはずだ。
だから話が噛み合わない。
764:デフォルトの名無しさん
07/06/29 18:19:37
このスレで会話するためにMFCでダイアログを作るときの総称を、
”MFCのダイアログエディタ”と今ネーミングして、
その内訳が”リソースエディタ”と”クラスウィザード”って呼んでるわけ。
話の途中で突っかかってくる、ユトリ＆キティだね。
馬鹿なんじゃないの?
765:デフォルトの名無しさん
07/06/29 18:21:41
＞だから話が噛み合わない。
そりゃ、話を噛み合わせたら最後さ。
＞あくまでリソースエディタとクラスウィザードは、
＞（連携はするが）別の機能と捉えているはずだ。
これらの連携がちょー使い難いんだからｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
766:デフォルトの名無しさん
07/06/29 18:23:51
絶対揺るがない結論：
MFCのダイアログ作成（リソースエディタ、クラスウィザード）は、
リソースエディタ単体を見ようが、
クラスウィザード使って連携させようが、
何をどう言い訳しても、超使い難い。
767:デフォルトの名無しさん
07/06/29 18:27:12
つまりWin16由来のリソーススクリプトが糞であり再利用性や柔軟性を
阻む代物なのであって、オブジェクト指向らしく組みたいのなら、MFCのように
リソーススクリプトに依存しつづけるのではなく、
TkやJavaのようにGUIコンポーネントを常に動的に生成配置するように汁
ということかしら？
768:デフォルトの名無しさん
07/06/29 18:33:23
>>767
それが要望の１点目。
もう一つ、ジェネレートするコード量を減らして欲しい。
第三世代言語＋コードジェネレーターの問題点はジェネレートされたコードを背負う事で、
それに対する解決策が差分コーディング。
注意：差分コーディングはOOPの本質じゃない、という反論禁止。ここで言いたいのは別の話。
次ページ最新レス表示スレッドの検索類似スレ一覧話題のニュースおまかせリスト▼オプションを表示暇つぶし2ch
5386日前に更新/201 KB
担当:undef