[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 1001- 2chのread.cgiへ]
Update time : 05/10 00:57 / Filesize : 201 KB / Number-of Response : 1002
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

MFCに嫌気がさした人の数→



1 名前:デフォルトの名無しさん [03/07/26 14:15]
特にゲーム製作には全然使えん罠

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

618 名前:デフォルトの名無しさん [2006/12/07(木) 18:26:04 ]
>MFC 8

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

619 名前:デフォルトの名無しさん [2006/12/15(金) 00:54:53 ]
俺はWEBアプリばかり作ってたから、未だにMFC未体験。

620 名前:デフォルトの名無しさん [2006/12/15(金) 01:36:29 ]
WEBとMFCになんの関係があるの?


621 名前:デフォルトの名無しさん mailto:sage [2006/12/15(金) 01:55:01 ]
どちらかというと、関係がないと言ってるように見えるのだが。


622 名前:デフォルトの名無しさん mailto:sage [2006/12/18(月) 14:09:11 ]
V$ドトネトに逝行してもMFC使ってる人っています?
逝行の致命的な問題とか無いでつか?

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

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


624 名前:デフォルトの名無しさん mailto:sage [2006/12/19(火) 11:24:20 ]
コモンダイアログ

625 名前:デフォルトの名無しさん mailto:sage [2006/12/19(火) 11:28:58 ]
>コモンダイアログ

MFCではない。



626 名前:デフォルトの名無しさん mailto:sage [2006/12/19(火) 12:12:14 ]
ダイアログテンプレート

627 名前:デフォルトの名無しさん mailto:sage [2006/12/19(火) 12:18:12 ]
Vi$taでもMFC使い続けますか?ドトネトにコンバートしますか?

628 名前:デフォルトの名無しさん mailto:sage [2006/12/19(火) 12:43:53 ]
>>623
ダイアログのリソース関連はまったく同意だなぁ
新しいプロジェクトはDLL化して分割管理しているからまだマシだけど
ずっとメンテナンスしてるプロジェクトがダイアログリソースだけでが250くらいあって
もうどうしようも無い感じなってきてる

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

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


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

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

631 名前:デフォルトの名無しさん mailto:sage [2006/12/19(火) 13:52:19 ]
ダイアログテンプレート

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

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

634 名前:デフォルトの名無しさん mailto:sage [2006/12/22(金) 08:46:43 ]
C/C++プログラマへアドバイス
ttp://www.01-tec.com/document/advise_to_programmer.html

(個人的にはMFCは VC++ の唯一の汚点だとも思っています^^;)ので、Windows系のプログラムを作るならこれ↓


635 名前:デフォルトの名無しさん mailto:sage [2006/12/22(金) 09:01:25 ]
いや・・・さすがにMFCとSTLを同列で扱ってたりするような糞サイトは参考にならんと思うが・・・



636 名前:デフォルトの名無しさん mailto:sage [2006/12/22(金) 09:10:27 ]
>MFCとSTL

MFCのCStringとstd::string問題を扱ってるだろ。

635=その問題を知らないとはC++使ってるとは言えない。

637 名前:デフォルトの名無しさん mailto:sage [2006/12/22(金) 09:10:45 ]
パソコンだって箱より中身の方が大事なわけだし
それがわかってれば箱なんか気にしない

638 名前:デフォルトの名無しさん mailto:sage [2006/12/22(金) 09:12:10 ]
ttp://program.station.ez-net.jp/special/vc/general/conpatible.asp

□ Visual C++ の互換性…

Visual Studio .NET を買って早数日…。

COM コンポーネントのバージョンアップを図るべく Visual C++ 7.0 にて ATL COM のプロジェクトをコンパイルしなおすことになりました。

□ MFC 7.0 と ATL 7.0

□ 変更点の補足

□ エラーを取り除く…

□ COM 動かず…

639 名前:デフォルトの名無しさん mailto:sage [2006/12/22(金) 09:13:29 ]
意味わかんないです(><)
ttp://www.microsoft.com/japan/msdn/netframework/programming/obsoleteapi/ObsByNamespace.aspx#System.Windows.Forms

System.Windows.Forms.Form
ApplyAutoScaling()
メッセージ : このメソッドは非推奨になりました。
代わりに、ApplyAutoScaling メソッドを使用してください。


.NET Framework 2.0 廃止予定の API 一覧
ttp://www.microsoft.com/japan/msdn/netframework/programming/obsoleteapi/

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



640 名前:デフォルトの名無しさん mailto:sage [2006/12/22(金) 09:24:10 ]
>>636
std::stringはSTLじゃないよ。

641 名前:デフォルトの名無しさん mailto:sage [2006/12/22(金) 09:30:03 ]
MFCもSTLもstringもC++のライブラリ。
同列に並べずどうする?

642 名前:デフォルトの名無しさん mailto:sage [2006/12/22(金) 09:41:51 ]
Windowsプログラミングを行うためのライブラリであるMFCと
標準ライブラリを同列に並べるの?libgnomeとlibcぐらい違うでしょ。
MFCのごく一部がC++標準ライブラリと被ってるのは確かだ。
だからMFCのコンテナを使うくらいならSTLのコンテナを使いましょうと言うならまだ分る。
要はMFC全体は標準ライブラリと排他的に選ぶものではないということ。

643 名前:デフォルトの名無しさん mailto:sage [2006/12/22(金) 10:02:05 ]
サイトには、
>MFC はC++のお手本として良い題材とは思いません。STL の勉強をお薦めします。
と書いてあるから、排他してなくて、勉強時にはMFCとSTL比べたらSTLを選べと言ってる。

>要はMFC全体は標準ライブラリと排他的に選ぶものではないということ。

おまいのいいがかりじゃん。


644 名前:デフォルトの名無しさん mailto:sage [2006/12/22(金) 10:17:32 ]
よく読めよ。MFCを勉強するかSTLを勉強するかではなく、
C++を勉強する時に使うべきはSTLかMFCかとおっしゃってるわけだが。

645 名前:デフォルトの名無しさん mailto:sage [2006/12/22(金) 10:21:02 ]
>C++を勉強する時に使うべきはSTLかMFC

C++を勉強するときに、STLとMFCと選ぶという行為は変じゃない。

その場合のSTLの選択も正しい。

で?



646 名前:デフォルトの名無しさん mailto:sage [2006/12/22(金) 10:22:21 ]
>STLとMFCと選ぶという

あ、ゴメンあいまいに書いちゃった。

C++勉強しよう。STLを勉強しようかな、MFCを勉強しようかな、という同列に並べた選択は変じゃない。
ごくふつー。

647 名前:デフォルトの名無しさん mailto:sage [2006/12/22(金) 10:28:15 ]
まぁ、MFC使って、
AppWizardの吐き出したコードの汚さに目が点、
画面に使えるコントロールが少ない、
それでも画面を何とかするにはActiveX使うしかない、
という流れでどうせ頓挫するさ。

という意味では、一旦MFC漬かってみれば結論でるお。

648 名前:デフォルトの名無しさん mailto:sage [2006/12/22(金) 10:44:40 ]
> C++勉強しよう。STLを勉強しようかな、MFCを勉強しようかな
作れるものが全然違うから同列に出来ないと俺は思ってる。
何かを作るのが目的でC++を勉強するってのが俺のスタンスだからだろうけど。
MFCを使ったコンソールアプリを作るのがMFCの勉強とは思えない。

堂々巡りでスレ汚しになる予感だ。
ケチ付けた方からで悪いが、この件はMFCの糞さとは関係ないからここら辺にしておこう。

649 名前:デフォルトの名無しさん mailto:sage [2006/12/22(金) 12:39:33 ]
>作れるものが全然違うから同列に出来ないと俺は思ってる。

「作るものが〜」という文脈は、作るのが目的の場合。

勉強する場合作るものはある程度何でも良くて、C++文法やクラスライブラリ構造の1例理解がターゲットだったりするわけ。

650 名前:デフォルトの名無しさん mailto:sage [2006/12/22(金) 16:29:04 ]
もうObjective-CとCocoaに移行すればいいじゃん。
そうすれば糞面倒なC++とMFCにもおさらば。

651 名前:デフォルトの名無しさん mailto:sage [2006/12/22(金) 17:11:43 ]
C++が面倒(やっぱ、慣れるまではちょっと面倒)なんじゃなくて、MFCが面倒。

それから、C/C++系ライブラリは必要、MFCは必須ではない。

652 名前:デフォルトの名無しさん mailto:sage [2006/12/22(金) 20:38:30 ]
一度でいいから見てみたい。
MFCを使わずにC++とWin32APIで
クラスの概念の存在意義を見いだせる書き方をされたコード。

653 名前:デフォルトの名無しさん mailto:sage [2006/12/22(金) 21:02:05 ]
ATL/WTLはどうですか?

654 名前:デフォルトの名無しさん mailto:sage [2006/12/25(月) 08:47:03 ]
>MFCを使わずにC++とWin32APIで

C言語とC関数ライブラリでひとかたまりのように、
C++とクラスライブラリで一セット。
分離はできない。

MFCを別のクラスライブラリに差し替えるのが正しい。

655 名前:デフォルトの名無しさん mailto:sage [2006/12/25(月) 11:34:32 ]
小物を沢山作る人なんかは自分で小さいクラスライブラリを作ってる事もあるね。
漏れも昔はやってた。



656 名前:デフォルトの名無しさん mailto:sage [2006/12/26(火) 04:41:55 ]
サードパーティの有料コンポーネント使った方が速いというか

657 名前:デフォルトの名無しさん [2006/12/26(火) 20:37:28 ]
サードパーティの有料コンポーネントってびみょーなのが多い
なんだこの程度のコンポーネントで売り物になるんだと思うことがほとんど。
自作したほうが、早い


658 名前:デフォルトの名無しさん mailto:sage [2006/12/26(火) 23:26:33 ]
wcはcの入門書の例題によく出てくるから、まあ範疇でいいじゃない。
wc sed grep lsなど簡単なunixコマンドは大抵win32版がgnuその他のフリーウェアで
転がっているから、ググレば拾えるよ。

659 名前:デフォルトの名無しさん mailto:sage [2006/12/26(火) 23:27:22 ]
>>658
やや、誤爆った。スマソ。

660 名前:デフォルトの名無しさん mailto:sage [2006/12/27(水) 09:16:40 ]
今ってネットにフリーのクラスライブラリのソースそのまんまのコンポーネントが溢れてる時代だよね。
MFCはマジでその辺が無い。

661 名前:デフォルトの名無しさん mailto:sage [2006/12/27(水) 09:20:26 ]
漏れはCodeProjectでさんざん世話になったが・・・

662 名前:デフォルトの名無しさん mailto:age [2007/01/03(水) 15:22:16 ]
ほっしゅ

663 名前:本田 [2007/01/03(水) 19:07:29 ]
>>652

owlnext.sourceforge.net/

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ヵ月ほどを費やした。




665 名前:デフォルトの名無しさん mailto:sage [2007/01/13(土) 13:25:12 ]
>>664
>久遠のプログラマー
マイクロソフトC/C++7.0はMFCなどの分厚いマニュアルが何冊も付いてきて、
パッケージの幅が50cmはあったと思う。
これを抱えたまま秋葉原駅の階段で転倒。腕の骨を骨折するに至った。



666 名前:デフォルトの名無しさん [2007/01/14(日) 02:10:59 ]
ワロタ

667 名前:デフォルトの名無しさん mailto:sage [2007/01/14(日) 03:28:18 ]
>>660
CodeGuru

668 名前:デフォルトの名無しさん [2007/02/09(金) 11:54:29 ]
Vi$taでもMFC使える?

669 名前:デフォルトの名無しさん mailto:sage [2007/02/09(金) 19:31:51 ]
>668
おいしい情報を教えるよ。

僕が開発した、「馬鹿には見えないMFC」を使えば、Vistaでもツルツル動くよ。
格安で譲って上げるから、レスちょうだい。

670 名前:デフォルトの名無しさん [2007/02/09(金) 20:50:33 ]
ツルツルage

671 名前:デフォルトの名無しさん [2007/02/10(土) 10:00:05 ]
メモリーフローコントロール

672 名前:デフォルトの名無しさん mailto:sage [2007/03/21(水) 03:27:23 ]
>>665
VisualC++1.0の紙マニュアル付きを思い出す
あれ買って帰った人いるのかなぁ

673 名前:デフォルトの名無しさん mailto:age [2007/04/01(日) 18:21:49 ]
あげあげ

674 名前:デフォルトの名無しさん mailto:sage [2007/05/02(水) 11:35:58 ]
MFCに四苦八苦しながらもようやくまともにアプリ書けるようになったと思ったら
.NETにWin64APIですか…orz

675 名前:デフォルトの名無しさん mailto:sage [2007/05/02(水) 15:15:49 ]
>>674
MFCよりゃ癖もなくて楽だと思うけどね。



676 名前:デフォルトの名無しさん mailto:sage [2007/05/05(土) 23:08:13 ]
MFCにかわるものはあるんですか?

(個人的にMFCは嫌いじゃない)

677 名前:デフォルトの名無しさん mailto:sage [2007/05/05(土) 23:09:23 ]
MFCの様にやりたいなら、MFCが一番だろw

678 名前:デフォルトの名無しさん mailto:sage [2007/05/08(火) 10:40:50 ]
MFC(GUIイマイチ) + VCL(某製) → .NET(モッサリ)

679 名前:デフォルトの名無しさん mailto:sage [2007/05/11(金) 20:43:21 ]
まぁ所詮「イジワルC++」ですから。

680 名前:デフォルトの名無しさん mailto:sage [2007/05/12(土) 00:07:23 ]
なんか、OrcasだとMFCも Vista対応されるんだな。

681 名前:デフォルトの名無しさん [2007/05/12(土) 18:26:10 ]
mfcはそこそこosに近い所で動きながらそこそこラクができるのが
いいんじゃないの。CWndベースで何でも作れるやん。

682 名前:デフォルトの名無しさん mailto:sage [2007/05/13(日) 15:52:29 ]
あれだなんだっけ?
メモリデバイスコンテキストとかセレクトオブジェクトで取得したもんを
開放したり確保したりかってにやってくれるのがいい
アレ、自分でやると開放していいのか悪いのかさっぱりわからん

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

683 名前:デフォルトの名無しさん mailto:sage [2007/05/14(月) 09:36:10 ]
>CWndベース

このクラス、Win32APIがくっついてるだけで、
変数も内部に保持しないわ、
楽にしてくれるメソッドは無いわ、
超スペシャルカス設計。

684 名前:デフォルトの名無しさん mailto:sage [2007/05/14(月) 11:03:01 ]
もともと、単なるラッパーとして設計されたクラスだもの。


685 名前:デフォルトの名無しさん mailto:sage [2007/05/14(月) 11:28:42 ]
>単なるラッパー

いや、単なるラッパーでも内部に変数保持する筈だし、
便利なメソッドが付いてる筈。

dデモキチガイ設計だお。



686 名前:デフォルトの名無しさん mailto:sage [2007/05/14(月) 12:50:59 ]
MFCのステートのカオス度は異常

687 名前:デフォルトの名無しさん mailto:sage [2007/05/14(月) 16:51:56 ]
え?何を内部に変数保存するの?

688 名前:デフォルトの名無しさん mailto:sage [2007/05/14(月) 16:55:12 ]
よくわかんねーけどインスタンスだろ

689 名前:デフォルトの名無しさん mailto:sage [2007/05/14(月) 17:02:42 ]
CPenとか内部に保持してくれたりリリースしてくれたりしないのは変杉。



690 名前:デフォルトの名無しさん mailto:sage [2007/05/14(月) 17:33:30 ]
設計当時、GDI上のハンドルは全てキャッシュだからなぁ。
Win16/Win95時代の設計なんだよ。

だから、どうしても変な実装になる。

691 名前:デフォルトの名無しさん mailto:sage [2007/05/14(月) 17:43:37 ]
VCLならちゃんとした設計になってるよ。
各コントロールやウィンドウがCanvasっていう抽象クラスを持ってて、
Canvasクラスがペンやメソッド持ってるお。

692 名前:デフォルトの名無しさん mailto:sage [2007/05/15(火) 09:09:01 ]
apiを直に使うのに慣れてたら違和感ないだろう
apiとやり方が全然違うとかえって使いにくいし

693 名前:デフォルトの名無しさん mailto:sage [2007/05/15(火) 09:17:47 ]
>apiを直に使うのに慣れてたら違和感ないだろう

違和感ありあり。

apiの機能を端折ることなくメソッド追加できるのが、クラスベース言語&クラスライブラリ。

クラスライブラリが無ければ、apiのラップ自体が開発となるのに、
目の前にトンでも設計便利なところ無しクラスライブラリを目の前に置かれると目が点。



694 名前:デフォルトの名無しさん mailto:sage [2007/05/15(火) 13:23:55 ]
>691
その実装も問題ありだな。
つーか、OS/2だと、DCとPSって分けられてたって知ってる?

695 名前:デフォルトの名無しさん mailto:sage [2007/05/15(火) 13:27:13 ]
何がどう問題なのか書かなきゃ意味無し。



696 名前:デフォルトの名無しさん mailto:sage [2007/05/15(火) 15:01:06 ]
ほう、ドリキャスとプレステで分けられてたのか。
三千院家の屋敷みたいだな。

697 名前:デフォルトの名無しさん mailto:sage [2007/05/20(日) 12:21:41 ]
たまにはWFCのことも思い出してあげてください…

698 名前:デフォルトの名無しさん mailto:sage [2007/05/22(火) 23:20:30 ]
ちゃんとしたものが作れるのであれば、なんでもいいよ。
MFCだろうとVCLだろうと。


699 名前:デフォルトの名無しさん mailto:sage [2007/05/23(水) 00:49:16 ]
WTL最強

700 名前:デフォルトの名無しさん mailto:sage [2007/05/23(水) 13:30:19 ]
ttp://www.net3-tv.net/~m-tsuchy/tsuchy/dvlp41a.htm

701 名前:デフォルトの名無しさん mailto:sage [2007/05/29(火) 14:45:22 ]
MFCで0xc0000135
ttp://forums.microsoft.com/MSDN-JA/ShowPost.aspx?PostID=1586822&SiteID=7

702 名前:デフォルトの名無しさん [2007/06/21(木) 16:15:40 ]
ttp://itpro.nikkeibp.co.jp/article/COLUMN/20070620/275330/
1990年代の中頃になると,主にCプログラマを対象とする,
比較的難易度の高いMicrosoftの「Win32 API」が,
さらに難解な「Microsoft Foundation Classes (MFC)」と「ActiveX Template Library (ATL)」に取って代わられた。
これら2つのC++フレームワークは,控えめに言っても,コンピュータ・サイエンスの歴史上最悪の出来事に含まれる。


703 名前:デフォルトの名無しさん mailto:sage [2007/06/21(木) 20:24:08 ]
えー、歴史を知ってる人はそんなに簡単に史上最悪とか言わないよー。
だって、必用があったから拡張されて複雑になるわけで、それなりの理由があるんだから。

704 名前:デフォルトの名無しさん mailto:sage [2007/06/21(木) 22:15:44 ]
こいつ只のMSアンチだろw

705 名前:デフォルトの名無しさん mailto:sage [2007/06/22(金) 08:36:53 ]
>必用があったから拡張されて複雑になるわけで

MFCに関しては当初から複雑。
GUIに関してはプロジェクトを超えて使いまわし出来ない。



706 名前:デフォルトの名無しさん mailto:sage [2007/06/22(金) 09:53:55 ]
>>705
>GUIに関してはプロジェクトを超えて使いまわし出来ない。
まさか、リソースIDに整数使ってたりする?

707 名前:デフォルトの名無しさん mailto:sage [2007/06/22(金) 10:13:58 ]
そういう問題じゃなくて、
resource.hの存在自体がoop的にはトンでもキティなの。


708 名前:デフォルトの名無しさん mailto:sage [2007/06/22(金) 23:25:25 ]
歴史的にリソースは CのSDKからそのまま持ってきたんだから、oop的にキモいのは当たり前なんだよな。
MFCが当初から複雑って、16bit時代のMFCの事を指してる?
当初は簡単なモノだったさ。


709 名前:デフォルトの名無しさん mailto:sage [2007/06/25(月) 08:38:39 ]
>MFCが当初から複雑って、16bit時代のMFCの事を指してる?

いや、今現在のヤツのダイアログ作成が超サイアク。

710 名前:デフォルトの名無しさん mailto:sage [2007/06/25(月) 12:34:53 ]
>709
最初のバージョンから比べると、今のダイアログ作成はかなり楽になった方だと思うけど。

最初のバージョンは、SDKのダイアログエディターしかなかったんだぜ。


711 名前:デフォルトの名無しさん mailto:sage [2007/06/25(月) 13:01:47 ]
>最初のバージョンから比べると、今のダイアログ作成はかなり楽になった方だと思うけど。

その比較に何の意味がある。

>最初のバージョンは、SDKのダイアログエディターしかなかったんだぜ。

イラネ

712 名前:デフォルトの名無しさん mailto:sage [2007/06/26(火) 22:33:20 ]
711は昔から常駐してるクソだから放置しとけ

713 名前:デフォルトの名無しさん mailto:sage [2007/06/27(水) 21:25:03 ]
歴史を知ってれば…って話前提なんだから、最初のバージョンの比較に意味はあるだろ。
このバカ。

714 名前:デフォルトの名無しさん mailto:sage [2007/06/28(木) 09:05:57 ]
現状がサイアクなのに、
>最初のバージョンから比べると、今のダイアログ作成はかなり楽になった方だと思うけど。
といった内容に何の意味がある。

このバカ。

715 名前:デフォルトの名無しさん [2007/06/28(木) 14:15:10 ]
> GUIに関してはプロジェクトを超えて使いまわし出来ない。

MFCベースで作成した拡張DLLで、複数のプロジェクトでGUIを共有
してますが、何か?



716 名前:デフォルトの名無しさん mailto:sage [2007/06/28(木) 14:47:18 ]
あの、それDLLの共有。

OOPでいうところの、ベースダイアログと派生ダイアログっていう共有じゃないでしょ。
ちょっと処理が違うダイアログ作ろうと思って、DLL変えてるようじゃoopじゃないから。
派生クラスを増やしても他の派生クラスのバグの元とならないことが重要。

717 名前:715 [2007/06/28(木) 15:30:10 ]
>>716
> OOPでいうところの、ベースダイアログと派生ダイアログっていう
> 共有じゃないでしょ。

それをやりたけりゃ、作成した独自ダイアログクラスを持つDLLから、
さらに別の拡張DLLなりアプリケーション側なりで、派生ダイアログ
クラスを定義すればいいだけでしょ?

そのやり方も知らないで、よくプログラマやってられるな〜。それとも
口先だけの自称システムエンジニア様か、自称ITコンサル様?(w

> 派生クラスを増やしても他の派生クラスのバグの元とならないことが重要。

そんなもんクラス設計する側に依存する問題であって、MFCに依存の
問題じゃねぇだろが。

いるんだよな〜。オープン厨房とか、自分のスキルや知識のなさを棚に
上げて、何か問題を起こすとWindowsやらMFCのせいにして、ひたすら
Unixの営業を始める香具師。






[ 続きを読む ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<201KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef