MFCに嫌気がさした人の数→at TECH
MFCに嫌気がさした人の数→ - 暇つぶし2ch486:デフォルトの名無しさん
06/06/01 21:44:54
>>485
勉強するならWTLを激しくお勧め。
きれいなソースで継承関係でもっさり感が80%減(MS社比)
VC++が出力する気味の悪いテンプレートに悩まされず、VCのバグに
巻き込まれにくい。
問題はドキュメントの数と認知度の低さ。趣味グラマーならWTL。

つーかMFCに勉強する所なんて無い。バッドノウハウの温床だよ。

487:デフォルトの名無しさん
06/06/01 21:47:59
WTLはVS2005 EEで使えないんじゃなかったっけ

488:デフォルトの名無しさん
06/06/01 22:02:41
>>487
使えない?(´・ω・`)

最悪make環境でも作れるぽ。効率悪いけどl。

489:デフォルトの名無しさん
06/06/02 00:46:39
意外とフレームワーク等を自作して使っている人って少ない?

490:デフォルトの名無しさん
06/06/02 00:48:50
Expressでも使えるようにできる
つーかMFCこそ使えないし

491:デフォルトの名無しさん
06/06/02 04:31:39
MFCのソースコードはもうAPIのサンプル集と思ったほうがいい
あれがオブジェクト指向だと信じられていた時代があった・・・

492:デフォルトの名無しさん
06/06/02 17:27:41
>>486>>489
WTLはATL抜きで使えないから俺も自作した。
ATL(の少なくともWTLに必要な部分)が自由に使えるのであれば、
文句無くWTLを使うんだけど。

493:デフォルトの名無しさん
06/06/02 17:36:32
>>492
Expressで使えるぞ
ATL3だがWTLはちゃんとサポートしてる
Express+WTLはExpressの存在理由だろう

494:デフォルトの名無しさん
06/06/02 22:35:11
>>493
Visual C++以外でもWTLを使いたいの。

495:デフォルトの名無しさん
06/06/03 19:00:37
MFCは、クソマクロや定数がちりばめられなければ
まだ使おうという気にもなるんだが・・・。

496:デフォルトの名無しさん
06/06/04 23:35:59
VBerにも使えるMFCには存在価値がある

497:デフォルトの名無しさん
06/06/05 08:38:13
>>496

断言するけど使えない。
C++を10倍難しいものにするMFC。

498:デフォルトの名無しさん
06/06/05 10:15:10
MFCだとメッセージ処理、WinAPIまでつっこまない(=時間の浪費)と
まともにプログラムできない。

それと国際化対応、スレッド、コンテナの直行性、モダンでないシリアル化がいまいち。
互換性が完全に足枷になってるんだな。(VC7.1Userです。VC8ってなんか変わったの?)

.NETはSTL.NETがまだ使えないので洗練されたコンテナが...


499:デフォルトの名無しさん
06/06/05 18:15:43
つまりVCL最強って琴田

500:デフォルトの名無しさん
06/06/05 20:48:07
いっそQTとか

501:デフォルトの名無しさん
06/06/10 07:03:23
MFCつかうと一気に実行ファイルサイズが10倍に?!

502:デフォルトの名無しさん
06/06/10 11:08:26
みんな!!MFCの悪口を言うなよ!

MFCも、今にきちんとするつもりなんだよ、きっと。





503:デフォルトの名無しさん
06/06/10 13:39:28
>>502
きちんとしようとした VB が VB.NET になったように
過去の互換性を捨てて MFC on .NET に!

…わりぃ、要らんわ。

504:デフォルトの名無しさん
06/06/10 13:51:44
Win32のラッパだからWin32があるかぎりMFCも使える。
Win32がなくなればMFCも不用

505:デフォルトの名無しさん
06/06/10 21:35:36
>>501
それはVCLwww

506:デフォルトの名無しさん
06/06/12 11:15:34
>過去の互換性を捨てて MFC on .NET に!

過去の互換性があるMFC on .NETも炒りませんが、何か?


507:デフォルトの名無しさん
06/06/12 20:54:47
  ∧,,∧
 (;`・ω・) MFC on .NET
 /   o━ヽニニニニニニフ))
 しー-J

508:デフォルトの名無しさん
06/06/13 07:10:06

        . n  T
          o  E
        F  N /|
       M C  //
          //
  ∧,,∧    //   |
 (;`・ω・)o  ̄  |
 /    /   |
 しー-J
 ウリャァ~

509:デフォルトの名無しさん
06/06/13 17:51:31
        |  |   |
  ∧,,∧
 (;`・ω・)  noT MEN FC.
 /   o━ヽニニニニニニフ))

510:デフォルトの名無しさん
06/09/06 16:09:14
VC++使ってますが、デバッグのトレースで、
STRCORE.CPPの240行目CString::CString(LPCTSTR lpsz)の中まで入ってしまいます。

入らない方法教えて下さい。

引数にCStringが有った場合、
ステップオーバー →メソッド通り越し
ステップイン →上記

で、困ってまつ。

511:デフォルトの名無しさん
06/09/06 16:26:39
MFCに嫌気が差したのなら使わないほうがいいよ。

512:デフォルトの名無しさん
06/09/06 17:30:01
>C++の効率的な勉強方法
スレリンク(tech板)
240 名前: デフォルトの名無しさん [sage] 投稿日: 2006/08/21(月) 22:56:44
ノシ
(Turbo)C++からいきなりはいったくちです。
Cは本(初めてのCだったけなぁ)読んで流した程度。
borland系のGUIクラスライブラリはOO的に綺麗な設計
でそれを解析しながら仮想関数とか勉強したっけ。
MFCを先にやってたらと思うと背筋が寒くなる。




513:デフォルトの名無しさん
06/09/06 17:50:37
これは痛いな。

514:デフォルトの名無しさん
06/09/06 19:49:32
俺と全く同じなんだが、そんなに痛いのか。

515:デフォルトの名無しさん
06/09/11 04:19:05
漏れも Turbo C++ で OWL 使いまくってた
あれのおかげで OOP 理解出来たし
MFC の糞さも使う前から分かったので未だに使ってない
Win32API + 自前クラスライブラリでウフフ

516:デフォルトの名無しさん
06/09/11 08:08:13
>>515
>MFC の糞さも使う前から分かったので未だに使ってない
なんだかなぁ。

>Win32API + 自前クラスライブラリでウフフ
MFCより良ければいくらか商売になるよ。

517:デフォルトの名無しさん
06/09/11 09:13:53
>漏れも Turbo C++

名前で混乱させられるね。

>MFC の糞さも使う前から分かったので未だに使ってない

ウィザードでソースコードジェネレートした時点できちゃな杉だよね。

画面の着色に関してはペンとか生成してWin32と変わらないどころか、
見通し悪いくらい。

何にせよ、MFCのメジャーバージョンうpが停止されて、
他環境に広がらなくて良かった。

518:デフォルトの名無しさん
06/09/16 19:40:15
なんかの本でMSKKの奴が必死に弁解してたな。
「MFCはあれでよかったんだ!!汚いのはねらってやってたんだ!!」って

519:デフォルトの名無しさん
06/09/16 23:42:12
あんなにCみたいなキャストさせるのはヤメテ・・・
まぁこれはWin32APIの段階からキャストは必要だといわれればそうだけど

520:デフォルトの名無しさん
06/09/20 14:14:49
CString Str1, Str2, Str3;

として、

Str1 = Str2 + Str3;

って書けたっけ?

strcat等のstr系でしか書けなかったっけ?

521:デフォルトの名無しさん
06/09/26 09:56:36
書けるけど、漏れは Str1 += Str2; Str1 += Str3; と書く。

522:デフォルトの名無しさん
06/10/02 00:57:21
MFC便利!!
APIガリガリうざい。


523:デフォルトの名無しさん
06/10/02 08:23:48
MFC苦汁の選択!!

524:デフォルトの名無しさん
06/10/02 09:16:42
APIガリガリが上手くラップされてないのがMFC

525:デフォルトの名無しさん
06/10/03 01:38:04
うまくラップされているものはあるのか?

526:デフォルトの名無しさん
06/10/03 02:25:16
なにいってんだVCLにきまってんだろぼけ

527:デフォルトの名無しさん
06/10/04 00:52:05
お決まりの回答だ。つまらん


528:デフォルトの名無しさん
06/10/04 08:59:22
VCLは良いんだけど、フリーで組み込みに使えてポトペタできるライブラリきぼん。

529:デフォルトの名無しさん
06/10/06 00:29:04
作れたら何でもいいじゃん。

MFCもVCLも、過去の遺産だろ?


530:デフォルトの名無しさん
06/10/06 08:45:07
VCLは過去からの遺産だけど今も使える。
というか、VCLの代わりが無くて困ってる。

531:デフォルトの名無しさん
06/10/07 23:08:36
>>482
いや、キミに読めないというだけのこと。
480の内容は板違いネタだが普通に読める。


532:デフォルトの名無しさん
06/10/07 23:13:21
そうは言っても480のレスなど理解する必要も無いような内容だがな
482の無知はここの板であれば罪ではない範囲
「自分に理解できない内容=統合失調」って短絡は失笑ものではあるが




533:デフォルトの名無しさん
06/10/08 02:04:47
wxWidgetsに移ろうよ。

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
かわいそうw

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に移ったのですがあまりの設計の悪さに「Cプログラミング診断室」
(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
世の中にはドトネトじゃないまともなクラスライブラリがあるわけだから、
M$のダサダサ開発環境捨てるべきじゃね?

ネイティブ、COM、ドトネトの三つ巴の関係を考慮しながら開発なんて超変だお。

554:デフォルトの名無しさん
06/11/14 12:00:05
>>551
>C#は結局C++に挫折した奴が書くスクリプト言語でしょ
いや、実行時にコンパイルされるCモドキのVB。

555:デフォルトの名無しさん
06/11/14 12:17:19
じゃ、ドトネトは巨大なVBランタイムか。

556:デフォルトの名無しさん
06/11/14 12:22:08
C++に挫折するやつはC#も書けない気がするけどなw

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)

 ( <●><●>)   ドトネト1.0~2.0廃止なのは分かってます
  (U      )つ  
    u  u


古臭いVCL >>>>> WinFX >>>>>> MFC

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実装+Viewの描画にポトペタ部品の派生が最強。

結論:ポトペタ部品の派生が簡単なVCL最強。(DelじゃなくてBCB)


575:デフォルトの名無しさん
06/11/20 09:35:40
MFCがOOPになってないところ羅列

・描画中にCBrushとか自分で生成破棄する必要がある。

576:デフォルトの名無しさん
06/11/20 09:37:42
それはOOPとは関係ないだろ

577:デフォルトの名無しさん
06/11/20 09:58:30
ウィンドウが自分を描画するブラシぐらい持つべきだろ。
持ってないならクラスにならん。

578:デフォルトの名無しさん
06/11/20 09:59:50
MFCがOOPになってないところ羅列

・ダイアログのリソースが1ファイルに収まるため、別プロジェクトがダイアログクラスを普通に共有できない


579:デフォルトの名無しさん
06/11/20 10:07:24
それはOOPとは関係ないだろ

580:デフォルトの名無しさん
06/11/20 10:23:38
CDialogクラス派生した部品が他プロジェクトの派生部品となりえない・・・アリエナス

581:デフォルトの名無しさん
06/11/20 10:25:36
MFCが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ツールでもお客の要求などからコントロールを1から書くことが結構ある。
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は3日あれば覚えられる



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はインストールしてあるw

616:デフォルトの名無しさん
06/12/07 18:04:42
MFCってVC++2005でもサポートされるんだっけ?
MFCのメジャーバージョンうpとかどうなんでしょ。

617:デフォルトの名無しさん
06/12/07 18:16:26
VC++ 2005 (Std以上)にはMFC 8が付いている。

618:デフォルトの名無しさん
06/12/07 18:26:04
>MFC 8

VC++6のMFCと互換性おk?

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
V$ドトネトに逝行してもMFC使ってる人っています?
逝行の致命的な問題とか無いでつか?

623:デフォルトの名無しさん
06/12/19 11:17:23
>CDialog1つに対してresource.hとrcファイルがあって、
>プロジェクトをダイアログ単位の部品クラスに分割できれば、
>まだ使えたようなキガスル

他のプロジェクトにダイアログをカレントプロジェクトにコピペといった使い方しかできないおね。
MFCのパワーユーザーとか、他のプロジェクトのダイアログをクラスライブラリとして使いまわせない事をどう思ってんだろ?


624:デフォルトの名無しさん
06/12/19 11:24:20
コモンダイアログ

625:デフォルトの名無しさん
06/12/19 11:28:58
>コモンダイアログ

MFCではない。

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化して分割管理しているからまだマシだけど
ずっとメンテナンスしてるプロジェクトがダイアログリソースだけでが250くらいあって
もうどうしようも無い感じなってきてる

629:デフォルトの名無しさん
06/12/19 13:20:11
ダイアログリソースって壊れやすいから嫌い。
変なマクロもぶちまけるし。

ソースとリソースを相互変換するツール作ればいいだけじゃ?


630:デフォルトの名無しさん
06/12/19 13:49:19
>ソースとリソースを相互変換するツール作ればいいだけじゃ?

つ BCBなら1ダイアログが3ファイル(.h/.cpp/.dfm)

631:デフォルトの名無しさん
06/12/19 13:52:19
ダイアログテンプレート

632:デフォルトの名無しさん
06/12/22 02:38:35
厨な質問だと重々承知しておりますが質問します。
WindowsオンリーであればMFC使った方がいいですかね?
世間の評価が気になるのですけど、MFC?:( ´,_ゝ`)プッてな感じになりませんか?

633:デフォルトの名無しさん
06/12/22 07:38:32
>>632
お好きなように。
>MFC?:( ´,_ゝ`)プッてな感じになりませんか?
MFC でも何でも、マトモなものが作れてるなら問題ない。

634:デフォルトの名無しさん
06/12/22 08:46:43
C/C++プログラマへアドバイス
URLリンク(www.01-tec.com)

(個人的にはMFCは 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)

 ( <●><●>)   ドトネト1.0~2.0廃止なのは分かってます
  (U      )つ  
    u  u



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 はC++のお手本として良い題材とは思いません。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++文法やクラスライブラリ構造の1例理解がターゲットだったりするわけ。

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
今ってネットにフリーのクラスライブラリのソースそのまんまのコンポーネントが溢れてる時代だよね。
MFCはマジでその辺が無い。

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などの分厚いマニュアルが何冊も付いてきて、
パッケージの幅が50cmはあったと思う。
これを抱えたまま秋葉原駅の階段で転倒。腕の骨を骨折するに至った。

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
ツルツルage

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が一番だろw

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
あれだなんだっけ?
メモリデバイスコンテキストとかセレクトオブジェクトで取得したもんを
開放したり確保したりかってにやってくれるのがいい
アレ、自分でやると開放していいのか悪いのかさっぱりわからん

あと、トラッカークラスとかいいw

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アンチだろw

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
クリエイターはS。(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と共にアナウンスではメジャーバージョンうp停止。
実際にはうpされたけどさ。
しかしだ、ドトネトに逝こう汁とは、いかがなものかと。

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専用ではないことすら知らない

こういう感じ。

間抜けだなあ。 wwwwwwwwwwwwwwwwwwwwwwwwwww


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使っていまいが、リソースのソースファイルの中身は
>テキストなので、普通にメモ帳とかで編集できるわけで、

 ↑
これが、”何をどう言い訳しても”っていう中身wwwwwwwwwwwwwwwwwwwwww

2回も同じことを書いて必死wwwwwwwwwwwwwwwwwwwwwwwwwww


やっぱり絶対揺るがない結論:


MFCのダイアログエディタ(リソースエディタ、クラスウィザード)は、
何をどう言い訳しても、超使い難い。


747:デフォルトの名無しさん
07/06/29 15:48:46
    _, ._
  ( ・ω・)       芝刈り機出動
  ○={=}〇,
   |:::::::::\, ', ´
.wwし w`(.@)wwww

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のダイアログエディタ(リソースエディタ、クラスウィザード)は、 何をどう言い訳しても、超使い難い。

こう書いているのに、
リソース形式の言い訳ばっかり(3回目w)書いた上に、

>MFC自体は、マイクロソフト謹製という点を除けば、C++で書かれたクラス
>ライブラリの1つに過ぎないし、完全なソースも付いていて、C++の基本が
>正しく理解できてさえいれば、さほど悩むことはない。

こういう文脈から外れた自分が上に立つための関係ないこと書き出して、イヤなヤツ杉る。



754:デフォルトの名無しさん
07/06/29 16:30:36
結論2:
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とか、まさにそんなもんだろ。

氏滅したブビを出すなんてヴぁかなヤシwwwwwwwwwwwwwwwwwwww
お前が知ってる世界はだっせー

757:デフォルトの名無しさん
07/06/29 16:45:17
>MFC自体もマイクロソフトも、MFCを使うことを強制してはいない。

当たり前だろ、M$社内でMFCなんてきちゃないもの使ってないよwwwwwwwwwwwwwwwwwwwww
お前はMFC使ってれば良いんだよwwwwwwwwwwwwwwwwwwwwwwwww

758:デフォルトの名無しさん
07/06/29 17:05:44
継承マダー?(AAry

759:デフォルトの名無しさん
07/06/29 17:06:07
再度指摘。
>MFCのダイアログエディタ

760:722
07/06/29 17:07:07
君の言うM$って、MSKKのことか?

まぁ、あそこはMS内部でも極めて特殊で、代理店統括みたいなコトしか
やってないから。MSKKで過去に開発した製品って、はがきスタジオ
くらいだろ。実態は、偽装請負だけど。(w

MSDNも別会社に丸投げしてるしな。

MFCはアップデートされないんじゃなくて、既に出来上がってる部分は
バグが枯れているんだよ。それに、MFC使ってる香具師は、自前の派生
クラスライブラリくらい構築していると思われ。

761:デフォルトの名無しさん
07/06/29 17:38:11
>再度指摘。
>>MFCのダイアログエディタ

MFCのダイアログエディタ=リソースエディタ+クラスウィザード

>君の言うM$って、MSKKのことか?

”君”ってエラソーだね。
違う。本社。

>継承マダー?(AAry

教えると損だから教えないことにした。


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
>だから話が噛み合わない。

そりゃ、話を噛み合わせたら最後さ。

>あくまでリソースエディタとクラスウィザードは、
>(連携はするが)別の機能と捉えているはずだ。

これらの連携がちょー使い難いんだからwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww


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
それが要望の1点目。


もう一つ、ジェネレートするコード量を減らして欲しい。

第三世代言語+コードジェネレーターの問題点はジェネレートされたコードを背負う事で、
それに対する解決策が差分コーディング。
注意:差分コーディングはOOPの本質じゃない、という反論禁止。ここで言いたいのは別の話。

769:デフォルトの名無しさん
07/06/29 18:54:55
継承マダー?(AAry

770:デフォルトの名無しさん
07/06/29 19:46:23
で、>>766 は、どこら辺が「超」使いづらいの?


771:デフォルトの名無しさん
07/07/01 00:46:34
ところでリソースファイルって無理やり1つのプロジェクトで複数呼ぶことってできるじゃん?
これってやっていいの?悪いの?
一応動くは動くんだけど・・・

複数人で開発してるとどうしても1つにまとめられてると不便でしょうがないんだよね

リソースファイル1つだと、
あるウィンドウ造ってライブラリみたいにしておいとくってできないじゃん
これが複数使えるようにすると結構便利になるんだが・・・

772:デフォルトの名無しさん
07/07/01 01:01:53
.rcと.rc2みたいにすりゃいいんじゃないの?

773:デフォルトの名無しさん
07/07/01 01:57:47
>>772
そうそうそうやってるんだけど
やっていいのか悪いのか判断がつかなくて・・・

774:デフォルトの名無しさん
07/07/01 08:40:48
で、>>766 は、どこら辺が「超」使いづらいの?

775:デフォルトの名無しさん
07/07/01 10:51:38
なんかマクロ+独自の変換ツールの記述が多くてかっこわり。

776:デフォルトの名無しさん
07/07/01 19:15:42
複数人で開発するのに、機能単位で担当者を振り分け、機能毎にDLL化
したりせず、一本糞みたいに、1つの実行ファイルにしちゃうマネージ
メントが、MFC以前にまさに糞だと思うんだが?

777:デフォルトの名無しさん
07/07/01 19:40:37
1つの実行ファイルにするかどうかと、ちゃんと分割統治されてるかどうかは別の話だろ

778:デフォルトの名無しさん
07/07/01 19:51:06
>>776
機能毎にDLL化って何がいいの?
すげーバグつかみにくい上になにも分離できねぇと思うんだけど

779:デフォルトの名無しさん
07/07/01 20:46:29
DLLに分割するのに必要な機能の洗い出しや切り分けをする能力も、DLLの
デバッグ手法に関する知識もないのに、まるで『DLL化していなければ、
たとえバグを出しても、すぐに見つけられる』とさえ言い出しかねない、
そんな >>778 に、一言どうぞ。



780:デフォルトの名無しさん
07/07/01 20:57:30
単純に設定とか面倒じゃんw

デバッグ版DLL
リリース版DLL
なんだかコンパイルオプションの設定が違っちゃったデバッグ版DLL
なんだかコンパイルオプションの設定が違っちゃったリリース版DLL

とかなり面倒で死んだw
プログラム以前の問題だった
こんなところで躓いてるわけにはいかないと思った

781:デフォルトの名無しさん
07/07/01 21:21:44
ひとつのプロジェクトでしか使用せず
再利用の機会がないDLLなら分割するメリットはない
単一の実行ファイルにしてしまっても問題ない

OSのAPI等のように複数のプログラムから共通に利用されて
初めてDLLにした意味が出てくる

782:デフォルトの名無しさん
07/07/01 21:26:11
そして数多のMSVCRTが混在しましたとさ

783:デフォルトの名無しさん
07/07/01 21:43:02
libも凶悪だよな
作者がなんも知らんで公開しててコンパイルオプションが
違うからコンパイルできんとかアリガチ
デバッグ版で配ってるとかよw

784:デフォルトの名無しさん
07/07/01 22:12:03
プログラムはソースで配布すべき

785:デフォルトの名無しさん
07/07/01 22:12:07
そこでLGPLですよ
#GPLv3公開されましたね

786:デフォルトの名無しさん
07/07/01 22:48:32
で、>>766 は、どこら辺が「超」使いづらいの?

787:デフォルトの名無しさん
07/07/03 00:44:29
>>784
俺はこれは反対だ。
ついうっかり1文字書き換えちゃっただけで終了

788:デフォルトの名無しさん
07/07/03 00:57:08
>>784
てか、あれ、バージョン管理を設置するべきだよね

789:デフォルトの名無しさん
07/07/04 01:09:56
>>787
そういうときのためにMD5がある訳だが
っつーかバイナリ配布でも1バイト書き換えたら死ぬだろ


790:デフォルトの名無しさん
07/07/04 09:00:12
>>789
MSって、ISOイメージを丸ごとダウンロードさせる場合でも、MD5値とか
正確なファイルサイズを公開していないケース多くない?


791:デフォルトの名無しさん
07/07/04 19:23:11
最近は付けてるみたいだけど
URLリンク(www.microsoft.com)


792:デフォルトの名無しさん
07/10/10 01:02:25
今更MFCつかったけど、糞だな

ダイアログベースじゃなきゃ、UI全て手書きかよ・・・

なんだこりゃ


793:デフォルトの名無しさん
07/11/04 13:11:03
MFC使うのと、API直接いじるのとでは、難易度はどのくらい違いますか?

794:デフォルトの名無しさん
07/11/05 11:17:54
APIはマニュアルみて使い方理解するだけだから簡単
MFCの方はAPIとの整合性を考えながら使わないといけないから面倒

APIを薦める



795:デフォルトの名無しさん
07/11/09 15:58:34
結局APIを調べることって必要になるんだよね。

796:デフォルトの名無しさん
07/11/09 16:04:19
MFCって、消えてなくなるの?
今さら勉強しても無駄無意味?

797:デフォルトの名無しさん
07/11/09 17:19:39
勉強したら悪いデザインが身に付くが。

例えば、
クラスライブラリなのに巨大なコードが吐き出されるとか、
ダイアログ部品少ないし部品がActiveXじゃ素直に派生できないとか、
ダイアログ作り難杉でやりたいことよりダイアログの記述が多いよとか、
結局描画するだけでもAPIコール、
みたいな。

798:デフォルトの名無しさん
07/11/09 22:40:04
アンチMFCなひとは

wxWidgets
gtkmm
FOX
その他

どれ使ってます?


799:デフォルトの名無しさん
07/11/10 03:39:05
.net

800:デフォルトの名無しさん
07/11/10 03:41:05
>>793
生API使っても、見栄えのするGUIを作るのはめちゃくちゃ大変だぞ。

801:デフォルトの名無しさん
07/11/10 03:57:00
MFCってダイアログしか作れないんでしょ?バカみたい。

802:デフォルトの名無しさん
07/11/10 05:38:00
はぁ?

803:デフォルトの名無しさん
07/11/10 16:39:49
>>801 が最強のバカに思える..

804:デフォルトの名無しさん
07/11/10 16:51:15
そろそろ完全に切り捨てないのかね
いつまでも使おうとする人がいて困る

805:デフォルトの名無しさん
07/11/11 00:46:09
ウィンドウの上半分をグラフ表示、下半分をリスト表示の画面を作るだけで
30分もかかった・・・

なんて生産性の低いツールだよ・・・

806:デフォルトの名無しさん
07/11/11 01:07:54
MFCみたいなライブラリはMSの小遣い稼ぎだろ。
技術に弱いけど知ったかが好きなIT企業経営者に
「MFCってのがあるらしい。これで作ると基本的なクラスはすでに提供されていて生産効率が上がるらしい。」
みたいな勘違いをさせて、ライブラリを売りつけているだけだろ。
うたい文句には誰かが騙されるものだ。エンドユーザーかもしれないし、一次受け企業の営業かもしれない。
「お金を出すから新しいライブラリで、既存のプログラムを書き直そう。」誰かがそういって犠牲者になる。
しかし本当のしわ寄せは一番末端の開発者に来る。
生産効率など上がるわけも無く、落とし穴に嵌り、それを力技で回避して息も絶え絶えに納品されたプロジェクト
つぎはぎだらけになったソースコード。
企業はそれをソフトウエア資産だとおもって再利用することに固執し、さらに生産効率が下がる。
赤字プロジェクトになり、開発者がサービス残業や、ボーナスカット、解雇といったしわ寄せを食う。
そのライブラリを作った詐欺集団の開発者は快適なオフィスで如何にMFCがすばらしいか、コラムを書いている。
つまらないアメリカンジョークも飛び出す、そんなコラムだ。
化けの皮が剥がれるころには次のフレームワークがリリースされている。



807:デフォルトの名無しさん
07/11/11 01:24:45
なんだこりゃ?10年前のコピペか??

808:デフォルトの名無しさん
07/11/11 01:55:26
まあ確かにオブジェクト指向だ、再利用だといっても、C++担ってからのほうがさらに
メンテが面倒になった気はする。
テンプレートとか消滅して欲しい。

809:デフォルトの名無しさん
07/11/11 02:55:02
>>806
釣りっぽいが、MFC使った方が生APIだけで作るより遥かに生産性高いよ
MFCやSTL、Boost、ATLも適所に使えばソースがかなり簡略化される
ソース再利用はライブラリがどうこうの話じゃなく、自分の問題だろ
自分で再利用可能なように作らず、汚いソース書いてるから再利用できないだけ
まぁ、後々まで考えて、再利用可能にする工数を会社が出さないもの一因だと思うけどな

ただゲームみたいな速度重視なら余計な被りものはデットウェイトになるのかな
業務系ならライブラリは十分使える


810:デフォルトの名無しさん
07/11/11 04:00:10
>>798
wxWidgets使っている。見た目も商用的に負けてない。
一度書いたGUIは、プログラムと完全に分離できるから資産化できるよ。

問題は英語の壁と、無料の拡張WidgetがUnicodeに対応していないことがある事。
自分的に気に入った点は、C/C++でめんどくさくなったらperl/pythonでも書けること。

811:810
07/11/11 04:02:44
宣伝です
URLリンク(www.wxwidgets.org)

812:デフォルトの名無しさん
07/11/11 04:30:13
>>809
たしかに有効である場面もあるんだけど大事な部分が抜けてるクラスとか多い気が
結局生APIいじる必要あったりしてそれを調べた分を考えると生産性が似たりよったり

まあ既に機能把握して使いこなしてるんだったら圧倒的に生産性高いのは認める
ただ会社の都合上すぐDLL化しろいいやがるのでMFC DLLを使うことになるのが鬱

813:デフォルトの名無しさん
07/11/11 07:48:04
VCLみたいな便利なクラスライブラリではなく
単なるAPIの薄いラッパーだということに気付いた15の夜

814:デフォルトの名無しさん
07/11/11 08:14:40
そうそう、MFCはクラスライブラリじゃなくてAPIラッパー。
ラップにところどころ穴があってAPIコールが必要orz

815:デフォルトの名無しさん
07/11/11 09:42:33
.NETはほんとうに美しい!!!
心もソースも洗われますよ。

MFCは
謎解きの荒らしなんで勘弁。


816:デフォルトの名無しさん
07/11/11 12:24:16
>>815
.NETは悪くない、寧ろMFCでCOMとか扱う苦労を考えたら .NET 最高っ、とか思う
ただ一点どうしても気に入らない部分がある
サブスレッドからコントロールを弄る時に…BeginInvoke()
こればっかりは簡便してくれと、なんかうまい手あんのかな

817:デフォルトの名無しさん
07/11/11 15:45:09
エディットコントロールの中身が実はウィンドウのタイトルバーを流用したものだと
独力で突き止めるのに半年かけたあの頃

818:デフォルトの名無しさん
07/11/11 19:05:42
Σ (゚Д゚;)ハッ この流れもしやDelphiオンリー?

819:デフォルトの名無しさん
07/11/11 20:30:10
まあMFCは重いってのも嫌われる理由かと
WTL使ってみるといいよ、かなり軽い
俺的には生API叩いてるのと大して変わらないと思うんだけどどうなんだろうか

820:デフォルトの名無しさん
07/11/11 23:27:32
.NETってインタプリタじゃん。コンパイラ言語と比べるなよ。

821:デフォルトの名無しさん
07/11/11 23:32:41
無知乙

822:デフォルトの名無しさん
07/11/11 23:39:46

JIT経由になるってだけで最終的にはネイティブだろ

823:デフォルトの名無しさん
07/11/12 00:48:53
働けど、働けど、バグ取れず
JIT手を見る。

824:デフォルトの名無しさん
07/11/12 16:29:03
ガベージコレクションのあるネイティブコンパイラなんて存在するのか?
いったいどんなコードにコンパイルされんの?

825:デフォルトの名無しさん
07/11/12 16:31:09
つD言語

826:デフォルトの名無しさん
07/11/12 16:38:18
>ガベージコレクション

クラスのローカル変数としての実体宣言オブジェクト

827:デフォルトの名無しさん
07/11/12 18:47:53
URLリンク(blogs.msdn.com)

すごくない?

828:デフォルトの名無しさん
07/11/12 19:07:21
IDEは凄いけど、中の人のMFCはダサいでしょ。
ってActiveX以外のコントロールを沢山使えるようになるとか、
中の人が丸々変わるんなら気体だけど。

829:デフォルトの名無しさん
07/12/02 14:10:15
age

830:デフォルトの名無しさん
07/12/28 18:12:18
age

831:ヽ・´∀`・,,)っ━━━━━━┓
07/12/28 18:14:44
>>827
WTLでくれ


832:デフォルトの名無しさん
07/12/29 01:48:16
MFCのクラス設計はクソだが、普通に使える。
コアなことやろうとしてもビルダーじゃどうにもならないしな。

833:デフォルトの名無しさん
08/01/02 00:22:08
>MFCのクラス設計はクソだが、普通に使える。
これは絶対に無いというのが、ここまでのレス。

>コアなことやろうとしてもビルダーじゃどうにもならないしな。
意味踏め

834:デフォルトの名無しさん
08/01/04 20:35:34
ムキになるなよ
MFC使ってマルチスレッドで痛い目見たから個人的にMFCは嫌い

835:マジレスさん
08/01/07 22:35:09
普通のアプリには使える。

コアなことやろうとするとC++Builderじゃつらいしな。

って言いたいんじゃまいか?
同意はできないけど。

836:デフォルトの名無しさん
08/01/08 14:20:38
>普通のアプリには使える。

無理。
だって、強制MDIでサイズ不変ののっぺらアプリになりがち。

>コアなことやろうとするとC++Builderじゃつらいしな。

絶対無い。

837:デフォルトの名無しさん
08/01/09 19:48:23
>>836
別に、既存のクラスやフレームワークをそのまま使わず、好きにオレ様
仕様のDoc-Viewでも実装すればいいだろう。

C++ Builderって、そもそも未来がないだろ。

838:デフォルトの名無しさん
08/01/09 20:33:37
オレ様仕様を実装するならMFC使う意味ね~~~ぢゃん!

839:デフォルトの名無しさん
08/01/10 00:59:21
>>838
そういうのは、まともにクラスの実装ができるようになってから言え。

結局、『MFCが使えない』と言っている本人自身が、「本当に使えない
ヤツ」ってことだろ?

840:デフォルトの名無しさん
08/01/10 01:39:33
>>834
MFCの同期オブジェクトの動きに翻弄された記憶があるので同意
スレッドに関してはAPI生で使った方が使いやすかった

841:デフォルトの名無しさん
08/01/10 08:36:30
一番汚いのはMFCで画面作成。
作りにくい、出来上がりがノッペラ。

842:デフォルトの名無しさん
08/01/10 08:38:44
>好きにオレ様 仕様のDoc-Viewでも実装

この内容って実は正しくて、Docに関してはフレームワークが勝手に弄ると、Docの中に処理を隠蔽するという事ができなくなる。
Doc-View間の連携はvectorへの参照程度なので、フレームワークが管理してくれる必要は無い。

843:デフォルトの名無しさん
08/01/10 15:43:32
>>839
× MFCが使えない
○ MFCは使えない

アンダースタンド?


844:デフォルトの名無しさん
08/01/10 20:48:10
マイクロソフト フライド チキン

845:デフォルトの名無しさん
08/01/10 21:21:18
マイクロソフト イズ チキン

846:デフォルトの名無しさん
08/01/11 07:24:41
こんなMFCはどうですか? ↓
URLリンク(www.mediafreakcity.com)

847:デフォルトの名無しさん
08/01/11 11:50:21
MFCに慣れてるけど、VistaやWindows7になったらイヤでも.NETを使わざる終えないのかな?

848:デフォルトの名無しさん
08/01/11 11:52:18
もしかして: 使わざるを得ない

いや2ちゃん語かとは思ったが。

849:デフォルトの名無しさん
08/01/11 12:00:40
MFCは終わるだろうけど、ドトネトはスルーしる!

850:デフォルトの名無しさん
08/01/11 16:07:14
そのうち、ドトネ一色になるだろう。

851:デフォルトの名無しさん
08/01/11 16:14:37
その前にM$がドトネト利用をアキラメタ。
オフィスとか。

852:デフォルトの名無しさん
08/01/11 16:25:27
でもクライアント企業は一度はまったら簡単には抜けられそうにないな

853:デフォルトの名無しさん
08/01/11 19:10:58
みんなそれに気付いたから、旧ブイビーに留まるか、ウェブ系に逃げてドトネトしないわけさ。

854:デフォルトの名無しさん
08/01/11 21:42:29
ドドメ色

855:デフォルトの名無しさん
08/01/11 23:00:23
そうかねえ
もっと早く.NET Frameworkを標準搭載するべきだったと思うんだが

856:デフォルトの名無しさん
08/01/12 02:14:21
>>849
まだだ、まだ終わらんよ

857:デフォルトの名無しさん
08/01/12 19:50:32
MFCの.NETラッパーが出て出て出てく出てく出てく出てくる

858:デフォルトの名無しさん
08/01/15 10:24:05
それってぐちゃぐちゃ。

Win32コードとAxをドトネトでラップなんて、中の人を追いかけるだけでしんどい。

859:デフォルトの名無しさん
08/02/07 03:24:48
MFCがいいところは、デバッグができるところだな。
Doc-Viewなんて使わなくても問題ないお

860:デフォルトの名無しさん
08/02/07 15:13:38
逆に商用でデバッグできないもんがあれば、教えてくれ!

VC++/MFCだとエラーダイアログが出て次の行をトレースできなくて困るけどね。
他のコンパイラならthrowしてるところでデバッガがステイしててくれる。

861:デフォルトの名無しさん
08/03/06 19:13:05
age

862:デフォルトの名無しさん
08/03/06 19:41:44
>>857
Windows FormsをホストするCWinFormsViewなら既にある。

863:デフォルトの名無しさん
08/03/08 15:14:07
ここまで読んで、VCLが非常に優れてるのはわかったけど
なんで死んでしまったん?

864:デフォルトの名無しさん
08/03/08 18:33:17
.NETで作ると、客先から「起動が遅い、何とかならんのか?」って必ずクレームが来ることを
覚悟して出荷せにゃならん

865:デフォルトの名無しさん
08/03/08 18:34:57
それは作りが

866:デフォルトの名無しさん
08/03/10 09:20:55
>>863
氏んだんじゃない。
VC++に搭載されないだけ。
VCLのパチモンはドトネトとして搭載されたけど、モッサリ(ry

867:デフォルトの名無しさん
08/03/12 03:31:15
C++/MFC去年はじめたけどカッコよすぎだろコレw

って思う俺はヘンなのか

868:デフォルトの名無しさん
08/03/12 09:18:41
ま、良んじゃない?
何食べてもおいしい人でしょ。

869:デフォルトの名無しさん
08/03/13 12:44:40
逆説的にとry

870:デフォルトの名無しさん
08/04/04 13:51:52
CArrayってサイズを拡張するとき、旧テーブル上のデータに対してデストラクタを呼ばずに
memsetで新しい配列にバイナリ・コピーするんだね(´ー`)
おかげでコンストラクタとデストラクタでthisの値が変わるとかいう現象が起こって
デバッグに半日つぶしたよ。死ねよ頼むから(´∀` )

871:デフォルトの名無しさん
08/04/05 13:28:32
デストラクタ発動もそれはそれでマズい
生成破棄に処理が伴うとか、あとウィンドウ登録される類の気を遣うべきクラスを格納するなら
CObject*やvoid*用のArrayやListでポインタだけ扱った方がいい

872:デフォルトの名無しさん
08/04/05 23:42:58
>>870
>CArrayって
標準コンテナ使わず、そんなうんこ臭いもん使うからだ。

873:デフォルトの名無しさん
08/04/06 02:39:36
MFCのビュー/ドキュメントがあまり好きではない
というか邪魔というか

かといってプロジェクト作成でドキュメント否定するとビューすら使わせてくれないのよね
デフォだと子ビュー的な名前のCWnd派生が出来る。ちょっとイヤ。手動で作れ。

874:デフォルトの名無しさん
08/04/06 11:26:58
もともとはマイクロソフトがワードやエクセルを開発するために、こしらえたもんだからな。
その余った部品をMFCとしてリリースしちまったんだ。
ワードやエクセルみたいなアプリを作るには良いかもしれんが
世の中すべてのアプリがそうとは限らない。
MFCが発表されたころはMDIアプリ全盛期だったが
その後Windows95とともにSDIが流行しはじめると
MFCがクソで使い物にならん事に気づいた。
MFCに見切りをつけてデルファイに流れた者もいた。
あれから10年以上も経って、まだMFC使ってるヤツおるんか・・・

875:デフォルトの名無しさん
08/04/06 17:23:55
Wordでさえ今はSDIだもんな
ExcelもさっさとSDIになってくれればいいのに

876:デフォルトの名無しさん
08/04/06 17:26:11
タブブラウザ全盛ですよ

877:デフォルトの名無しさん
08/04/06 17:36:35
MDIはapiレベルで実現してる機能だろ
何でSDIが流行しはじめるとMFCがクソなんだ?

878:デフォルトの名無しさん
08/04/06 18:59:34
そうだぜ、MDI・SDIに関係なくMFCは糞だ
なんか大事な部分が抜け落ちたりしてるので結局自前で実装したりする部分が多すぎる

879:デフォルトの名無しさん
08/04/06 19:35:08
MDI・SDIなんて何つくるかにも依るとは思うけど
基本的にアプリ開発選択でデフォにしておくものではないよなぁ。MDI

あとVBチックなダイアログベースアプリも簡単に作れはするけど
WinAppの初期起動中にアプリ(CDialog)寿命完結するというなんかイレギュラー臭い仕様が気になるw

880:デフォルトの名無しさん
08/04/12 09:15:47
今からC++とMFCをゼロから勉強するのって意味ないでしょうか?

881:デフォルトの名無しさん
08/04/12 13:17:13
医者になるんだったら意味無いな

882:デフォルトの名無しさん
08/04/14 10:54:13
C++は勉強しる。

883:デフォルトの名無しさん
08/04/14 22:16:00
>>880
目的は?
C++とかMFCとかは手段なのだから、目的に応じてやればよいこと。
プログラムの勘所がわかれば環境なんてどーにでもなる。


884:デフォルトの名無しさん
08/04/14 22:34:38
resource.hも
.rcも結局直にいぢるハメになり余計な時間を喰っちまうぞボケー

885:デフォルトの名無しさん
08/04/14 23:45:49
学校の課題?

886:デフォルトの名無しさん
08/04/15 08:43:46
>環境なんてどーにでもなる。

どーにでもならないのがMFC。

プロジェクト超えてふつーにダイアログを派生とかで使い回しできないのには超まいる。

887:デフォルトの名無しさん
08/04/15 23:07:24
>>886
発言の意味を理解してないのにコメントすんなってw

888:デフォルトの名無しさん
08/04/16 11:53:11
>ダイアログを派生とかで使い回しできない
拡張DLLがそんなにいやなのか。

889:デフォルトの名無しさん
08/04/16 11:59:07
そりゃ、超ヤダよ。

ダイアログはCDialogから派生になってるんだから、あるダイアログをプロジェクト毎に派生して使いたいだろ、常考。

890:デフォルトの名無しさん
08/04/19 11:07:58
自分で派生クラス作れんのか( ´ω`) そりゃ苦労するな

891:デフォルトの名無しさん
08/04/19 23:30:33
既存部品の派生でないとマトモに扱ってもらえないが
その派生元の既存部品の内部処理から来る妙な仕様とかを知ってないと
意味不明のバグとか出しやがる

892:デフォルトの名無しさん
08/04/25 15:20:56
学校でプログラミングしてたら先生に「なんでMFC使ってないの?」って聞かれたから
「MFCってめんどくさそうで使ってないんです。」って応えたら
「最初から自分で作るより早いし便利だよ。」と言われた
なんかMFCって自由を奪われてる感じがして気持ち悪いんだが、
俺はMFCを覚えたほうがいいのかな?

893:デフォルトの名無しさん
08/04/25 22:14:40
いいえ。。。

894:デフォルトの名無しさん
08/04/26 02:34:38
↑番号がゴクドー

895:デフォルトの名無しさん
08/04/30 08:28:51
>>892
既存ライブラリを使ってプログラミングすれば、その流儀に合わせなくっちゃならない。
自由を奪われる感じはあって当然。
なので、自由を奪われてる感じがして気持ち悪いことを理由にしていたら、どんな既存ライブラリも使えない。

ずっとこの先、一人でプログラミングしていくつもりなら、俺様クラスライブラリを作ればいいやん。がんばれ。


896:デフォルトの名無しさん
08/04/30 08:50:44
>俺様クラスライブラリ

この傾向が強すぎるのがMFC。
他環境で使えないし、WinでもつかえねーやつだからM$社内でも別のクラスライブラリが作られた。
関わらないがよし。

897:デフォルトの名無しさん
08/04/30 21:24:51
>>896
主観と噂と陰謀論だね。

898:デフォルトの名無しさん
08/05/01 12:34:49
単なるC++ラッパだからな
使いにくくて当然

899:デフォルトの名無しさん
08/05/02 21:48:09
えーっと、皆さん。
Visual Studioで使える、MFC以外のC++ クラスライブラリって何をお使いでしょうか。


900:ヽ・´∀`・,,)っ━━━━━━┓
08/05/03 18:56:50
.NET Framework(笑)






じゃなくてこうか?

ATL
WTL
STL
Boost
Loki port
Blitz++
Xerces C++

901:デフォルトの名無しさん
08/05/03 23:44:37
いや、名前だけ知ってるのをリストアップしろってんじゃ無く、
自分がどれを使ってるか、ってのを聞きたいんじゃないかな?

902:デフォルトの名無しさん
08/05/03 23:52:33
WTL使えばMFC使う気なくなるな

903:デフォルトの名無しさん
08/05/04 00:15:21
けど、WTLってあんましメンテされてないように思うんだけど…。
ATLのバージョン毎にマクロがきられすぎてて、どう書けば正しいのかが
さっぱり…。
MFCも2008FeaturePackの多言語版(SP1)がつけば一気に盛り上がるんでは?

904:ヽ・´∀`・,,)っ━━━━━━┓
08/05/04 01:23:49
>>901
一応利用経験あるライブラリしか列挙してないが

905:デフォルトの名無しさん
08/05/04 09:33:34
>>904
齧ったのを使っているとは言わないです。

906:ヽ・´∀`・,,)っ━━━━━━┓
08/05/04 12:47:07
それでもBoostまでは普通に常用してるわ

907:デフォルトの名無しさん
08/05/04 15:13:28
OWLってなかったっけ?

908:ヽ・´∀`・,,)っ━━━━━━┓
08/05/05 08:37:03
それ昔のTurbo C++

909:デフォルトの名無しさん
08/05/05 19:49:46
>>908
昔のTurbo C++ってDOS版だよな。 ソレに付いてたの確かTurbo Visionだぞ。
OWLはBorland C++になってからWindows対応クラスライブラリとして添付されたはず。

910:デフォルトの名無しさん
08/05/05 23:56:13
gethtmlwのWindow ClassがOWL_Windowになってるな。

911:マイク ◆yrBrqfF1Ew
08/05/19 10:11:08
ロクに使ったことないけどQtの方がキュートty(形容詞)だな。

912:デフォルトの名無しさん
08/06/08 01:29:49
MFCでいいじゃん

913:デフォルトの名無しさん
08/06/21 23:32:21
MFCってww

914:デフォルトの名無しさん
08/06/26 00:21:57
クロスプラットフォームを意識するならwxWidgets

915:デフォルトの名無しさん
08/06/28 21:22:49
意識しなくてもwxWidgetsかQtのほうがMFCより作りやすい気がする

916:デフォルトの名無しさん
08/06/30 08:49:24
分かったからwxWidgetsとQtのどちらが良いか教えてくれ。

917:デフォルトの名無しさん
08/06/30 19:40:14
自分で試せよ

918:デフォルトの名無しさん
08/07/01 09:52:49
どっちも触ったこと無いけど、名前の感じがいいからwxWidgetsで

919:デフォルトの名無しさん
08/07/09 00:01:51
MFCってそんなに使い勝手悪いかな?
VCLやwxWidgetsよりは間違いなく使いやすい

920:デフォルトの名無しさん
08/07/09 00:51:34
DirectXもそのたSDKも全部統合して欲しいです><

921:デフォルトの名無しさん
08/07/09 12:19:00
Win32 APIに明るい人ならMFCわかりやすいかもね
オブジェクト指向ではなくて単なる「便利なC」だけどな

922:デフォルトの名無しさん
08/07/09 12:36:39
いや。分かりにくい

923:デフォルトの名無しさん
08/07/09 15:25:01
「MSの想定した使い方をする限りでは楽ではあるが
そこから離れようとするとえらい労力を使わされる」
てとこだな。

924:デフォルトの名無しさん
08/07/09 16:37:11
MFCが使いやすいって言ってる奴は、
オブジェクト指向思考してないんじゃなかろーか。
違うかな?

925:デフォルトの名無しさん
08/07/09 16:53:32
16ビットの頃から C で書いてきた延長でそのまま使ってるからだよ。
適当に考えなしで使えるフレームワークとしていいべ

926:デフォルトの名無しさん
08/07/09 17:51:41
MSの想定した使い方なら確かに動くし、ある意味簡単
でも、それって、知ってれば簡単に書けるだけで調べるには骨が折れる。
結局覚えたら簡単ですよっていうレベル。
ならWin32でもおなじこっちゃ。覚えりゃ簡単です
MFCの悪いところは、「本当に意図したとおりに動くの?」の見極め作業がいること。
結局MFCソースみないと確信が持てない
変な動きをし始めちゃったら、結局MFCがどういうカラクリなのか調べる事に。この作業のほうがデカイ。
そして結構使っちゃいけないクラスとかある(あった)
ヘルプで良いことがいっぱい書いてあるから便利にラッピングしてくれてるのか?
と期待するが、そんな期待があたったためしもなし。CSocketとか。
結局Win32のめんどい手続きはそのまま隠蔽化しているクラスが
同じ程度の煩雑なメソッドで置き換えているだけ。
だったら最初からWin32で書いたほうがええっちゅーねん。


927:デフォルトの名無しさん
08/07/09 19:21:38
WTL

928:デフォルトの名無しさん
08/07/10 10:28:38
J++用にWFCってのがあった記憶

ドトネトには〃

※以下、無限ループ

929:デフォルトの名無しさん
08/08/08 17:13:22
MFCは何というか。。。

・Appwizard(コードジェネレータ)が生成した部分とユーザがコーディング
した部分の区別がつかない(せめて色分けしてくれるオプションがあったら
いいのに)

・普通ユーザがいじくるはずもない詳細な部分のコードまでさらけ出し過ぎ

・CdialogベースとCViewベース、SDIとMDIを最初の段階できめたら
途中で変更するのが難しい。

・同じ型を開発グループごとにtypedefで別々の型名使っているため
混乱する。

・ヘルプファイル見て調べろというけどHelpファイルは自動英訳ソフト
で変換したんじゃないかというくらい日本語になってない。わけわからん
解説よりも簡単なサンプルプログラムを乗せとけ!

フォームやダイアログのサイズ、背景色、コントロールの色などを変更する、
といった要求はごく普通なことだと思うのだが、プロパティシートにそう
いうパラメータを設定する項目がない。プログラムで変更しなければなら
ない。逆に、枠に境界線を設けるとか、3次元的に表示するとか、しょーも
ない項目しかプロパティシートに乗ってない、MFC作った奴は一体どういう
頭してたんだと腹が立つ。

・ちょっと「こういうことがしたい」と思っても簡単にはできない。MSDNを
調べても該当の箇所にヒットするのが難しい、ことばがわかりにくい。
結局、MSDNは諦めてgoogleや掲示板で調べるしかない。

正直、C#と比べると、時代遅れ。

930:デフォルトの名無しさん
08/08/08 17:19:50
懐かしいスレが上がってるな
C++ビルダーがいいよ



931:デフォルトの名無しさん
08/08/08 20:58:22
英語読めないでソフト作ってる人って頭おかしいの?

932:デフォルトの名無しさん
08/08/08 22:55:06
>>929
>・CdialogベースとCViewベース、SDIとMDIを最初の段階できめたら
>途中で変更するのが難しい。

そんなの必要か?
普通コーディングに入る前に十分な設計/検討をし、DRもやってから
コーディングに入った時点で変更なんてほぼありえないし、あっちゃまずい

933:デフォルトの名無しさん
08/08/08 23:38:34
>>932
そういうのが簡単にできないのが関数開発とかウォーターフォール。
オブジェクトのプロパティ変えるだけでできるべき。

934:デフォルトの名無しさん
08/08/08 23:54:13
日曜プログラマな俺にはMSのIDEの出来は素晴らしいと思う

935:デフォルトの名無しさん
08/08/08 23:55:01
簡単に変えれるかどうかが問題ではなく、基本設計をコーディングの際に変更がまずい

コーディングなんてのは現場の土方にでもやらせてればいい

土方に簡単に変更なんざできるはずない

936:デフォルトの名無しさん
08/08/09 00:57:54
>>935
それ>>932が言ったよ。
俺日曜PGだから分からんけどSEもPGも土方だよね?
PM以外みんな土方じゃないの?
そもそも1年や2年でモノ作れるようになれる業界じゃぁお金握ってる人以外皆同じでしょ?

937:デフォルトの名無しさん
08/08/09 15:44:08
っていうか、そういう開発工程の話じゃなくて
仕事で軽く使えるツール作るとか、ちょっとした個人用アプリ作るとかのときに
手軽に簡単に使えるのがライブラリってもんだろと俺は思う
だからこそ、appwizardでMDI/SDIが簡単に選べたりすうんだし

938:デフォルトの名無しさん
08/08/09 16:04:30
>>936

違うよ。
たとえば建設関係で言えば、設計士は設計、施工管理もやるし
現場の作業の内容も把握している。

でもPMはたたき上げでもないかぎり進捗管理くらいしかできない。

939:デフォルトの名無しさん
08/08/09 16:46:07
MFCが手軽とはとても思えない。SDKやったことがある人はわかるだろうし、
ありがたみもわかるんだろうけど、これを初心者が使いこなすのはしんどい。
ある程度のテクニックをもった人がそばにいてヒントを与えてくれるなら
いいが。


940:デフォルトの名無しさん
08/08/09 17:04:52
「プロパティが無い」だの「そばにいてヒント」だの・・・

・・・あ、夏休みか・・・

941:デフォルトの名無しさん
08/08/09 17:05:36
そもそもWindowsのGUIが扱いづらすぎる
せめて.NET風に扱えるライブラリがあればなあ

942:デフォルトの名無しさん
08/08/09 17:10:57
.NET をつかえばいいじゃないか。
MS は MFC より .NET を推進したいんだろうから。

943:デフォルトの名無しさん
08/08/09 17:11:38
>>939
気軽に聞けるある程度のテクニックをもった人がいない初心者が、
いきなり"MFCを使いこなせる"と思うほうが変だろう。
それはSTLでもboostでも同じことに思えるし。

使わなければならない人や、(使わないより)使ったほうが楽だと思える場合だけ、
七転八倒すればいいだけじゃね?

944:939
08/08/09 17:13:52
気軽に聞けるある程度のテクニックをもった人がいない初心者が、

気軽に聞ける「ある程度のテクニックをもった人」がいない初心者が、
に訂正、、しても読みにくいか。 まぁいいや。

945:デフォルトの名無しさん
08/08/09 20:41:08
>>939
えー。俺一人でMFC使えるようになったよ。
MFC Internalとか読んでMSDNと格闘しただけで普通に使えるよ。
これだから日本の職業SEPGは無能なんだよ。

946:デフォルトの名無しさん
08/08/09 22:17:34
>WindowsのGUIが扱いづらすぎる
X Window Systemの方が遥かに大変です

947:デフォルトの名無しさん
08/08/10 15:48:52
>>944

なり済まし乙

>>940

いいから、もう夏休みとれ。あっ、残業で休みもろくにとれないか。
ゴクロウw

948:デフォルトの名無しさん
08/08/11 15:20:53
>MFC Internalとか読んでMSDNと格闘しただけで普通に使えるよ。

 ↑
使えない道具を使えないと理解できないどしろーと。
料理でいえば何食べてもおんなじ人。


M$社内でさえ使われずに終焉したMFCの次スレはイランだろw

949:デフォルトの名無しさん
08/08/11 15:43:40
>M$社内でさえ使われずに終焉したMFCの次スレはイランだろw
いろいろな意味でアホやね。


950:デフォルトの名無しさん
08/08/11 15:52:48
ほんとそーだね。
M$社内で使われなかったものを使うのもアホ、
メジャーバージョンうpを表明されて終焉したMFCを使うのもアホ、
MFCをかばうのもアホw

951:デフォルトの名無しさん
08/08/11 16:49:50
恥の上塗りってやつ?

952:デフォルトの名無しさん
08/08/11 16:51:17
そうそう、嫌気がさしたスレでMFCをかばうのは恥の上塗りwww

953:デフォルトの名無しさん
08/08/11 17:29:03
夏休みらしいレス・・・もうちょっと冷静になって自分の書いたもの読んでごらん。

954:デフォルトの名無しさん
08/08/11 17:31:41
 ↑
内容では反論できない超ヴぁかwwwww

955:デフォルトの名無しさん
08/08/11 17:41:40
自分が理解できないものは、いろいろと貶したくなるものだね。

956:デフォルトの名無しさん
08/08/11 17:48:21
 ↑
恥の上塗りってやつ? wwwwwwwwww


957:デフォルトの名無しさん
08/08/11 17:54:16
わかります。優しく同情されると悔しいですね。
草を生やして誤魔化してみたくなるものです。

958:デフォルトの名無しさん
08/08/11 18:00:57
 ↑
夏休みらしいレス・・・もうちょっと冷静になって自分の書いたもの読んでごらん。 wwwwwwwwwwwwwww

959:デフォルトの名無しさん
08/08/11 18:09:32
え? MFCを使えない?

あれぐらいサラッと使えるでしょーに。

960:デフォルトの名無しさん
08/08/11 18:15:19
はいはい。あんな、つまらんものを使えるって言う馬鹿はいったい


961:デフォルトの名無しさん
08/08/11 18:20:29
Sour Grapes

962:デフォルトの名無しさん
08/08/11 18:24:03
「つまらんものを使えるって言う馬鹿」と「つまらんものを使うって言う馬鹿」
の間には大きな隔たりがあるのだと再認識しました。





963:デフォルトの名無しさん
08/08/11 18:27:45
M$脳って怖いね。
推奨がどんどん変わり続けて消えていってるのに気がつかないんだろうかね。

964:デフォルトの名無しさん
08/08/11 18:29:55
どうすればいいんだ!

965:デフォルトの名無しさん
08/08/11 18:30:26
つ C++ Builder

966:デフォルトの名無しさん
08/08/11 18:34:15
いまさら

967:デフォルトの名無しさん
08/08/11 18:36:11
でもない

968:デフォルトの名無しさん
08/08/11 18:36:24
「M$」みたいに手垢のついた表現を臆面もなしにする人ってなんだろな。

「M$脳って怖いね」なんて書いているのに、Windowsべったりな人って馬鹿を超越しているね。


969:デフォルトの名無しさん
08/08/11 18:37:10
968=M$脳

970:デフォルトの名無しさん
08/08/11 18:38:05
>C++ Builder

吹いた

971:デフォルトの名無しさん
08/08/11 18:40:19
>>963って、Microsoftの推奨を追っかけていて、それに忠実であろうとしている人なんだね。

972:デフォルトの名無しさん
08/08/11 18:42:10
MFCはMicrosoftの推奨でもないし、
ペタペタ貼り難いし、
メジャーバージョンうpオワタし、
何の目的で使う???

973:デフォルトの名無しさん
08/08/11 18:45:20
もう終わったんでつよ、MFCは?
MFCに関するソースも終わるってことですよ、VBのように?

974:デフォルトの名無しさん
08/08/11 18:46:26
>MFCに関するソースも終わるってことですよ
日本語でOK

975:デフォルトの名無しさん
08/08/11 18:49:12
MFCは終わりました。

976:デフォルトの名無しさん
08/08/11 18:53:14
Visual Studio 2008でかなり強化されて、そのあとも Feature Pack がリリースされてるわけで。

それにしても笑った。→ペタペタ貼り難いし

977:デフォルトの名無しさん
08/08/11 19:10:07


それにしても笑った。→Visual Studio 2008でかなり強化されて、そのあとも Feature Pack がリリースされてるわけで。

978:デフォルトの名無しさん
08/08/11 19:11:08
いつまでもゴミ駄目のMFCにしがみ付いてちゃダメだよ。

979:デフォルトの名無しさん
08/08/11 20:21:09
痛い粘着が湧いてるな

980:デフォルトの名無しさん
08/08/11 20:29:58
>>979
1000近づいているし、埋めネタにはちょうど良かったじゃないか。
あとはあほが次スレ立てなければ問題ない。

981:デフォルトの名無しさん
08/08/11 22:53:24
MFCを糞なんていう奴って挫折しただけでしょ?
事実上デファクトスタンダードだろ

FA業界じゃ、.NETなんて使い物にならん

982:デフォルトの名無しさん
08/08/11 23:26:07
所詮MFCを使いこなせなかった厨房がほざいてるだけですよ

983:デフォルトの名無しさん
08/08/11 23:37:25
WTL使おうぜ!
と言いたいところだがUIにもこだわらないといけない時代にはちょっと厳しいか

984:デフォルトの名無しさん
08/08/12 00:09:38
MFCとかOTLとかわけわかんねぇ!

985:デフォルトの名無しさん
08/08/12 00:52:45
なんつーかな。
MFCを使いこなせる、こなせないの問題じゃないよね。
ここに来てる人は、みんな使いこなしてるだろーよ。
だけど、世の中にはもっとすぐれたライブラリもあるわけで。
そういうライブラリがデファクトになった方が、よりハッピーになれるじゃん。
そう思わねぇ???

986:デフォルトの名無しさん
08/08/12 06:19:28
>>985
>だけど、世の中にはもっとすぐれたライブラリもあるわけで。
例えば?




987:デフォルトの名無しさん
08/08/12 08:21:34
馬鹿にレスすんなよ馬鹿が

988:デフォルトの名無しさん
08/08/12 08:41:52
WxWigets, Qt, VCL, etc...


次ページ
最新レス表示
レスジャンプ
類似スレ一覧
スレッドの検索
話題のニュース
おまかせリスト
オプション
しおりを挟む
スレッドに書込
スレッドの一覧
暇つぶし2ch