教えて！！ＭＦＣのわるいとこ

一ヶ月前に、はじめて業務上でVC++を使ったWindowsアプリを作る機会に恵まれて、
MFCを使ってみたんですけど（といってもダイアログベースの小規模なものですが）
「MFCって結構使いやすいのでは？」
っていう感想を持ちまして、これからもMFCを使っていこうと思うのですが、
この板で、「MFC逝ってよし!!」といった意見を目にするのが、
少々不安な部分であります。

MFC初学者（CWinAppと代表的なCWnd派生クラスとCCriticalSection位しか
使ってみたことがない）に、これからMFCを学ぶ場合の注意点等をご教授
いただけないでしょうか。

ちなみに、自分自身の今までの感想は、CWndクラスってウインドウクラスの基本的な使い方を
ちゃんとカプセル化してるし、フック用の仮想関数もあるし、ウインドウハンドルを
公開メンバにしてあって、APIの薄いラッパとなるように考えてあるし、
逝けてるじゃん！！といったものです。
では、よろしくお願いします。

ちょっと自信ないけど、とりあえず感じるのはCView派生からCDoc派生
にアクセスする方法が無い事（UpdateAllViewの逆）

CView派生のソースにCDoc派生のヘッダーを読めばいいけど、
アプリ毎にCView派生のソースを書き換えなきゃいけないのって
変だよね、、、

>1
君の分析は正しい。
ＭＦＣは世界中で使われていて、長年の実績もある。

ＭＦＣってWin32APIをベースにラッピングしてるだけなので
結局APIの知識が必要になる。Windows環境であればMFC+API呼び出しで
だいたいの事はできるけど、作りたい処理（まぁプログラムの要求仕様）
以外に記述する部分が多くなってかなりめんどくさい。
逆にVCLなんかだとVCLを使うユーザー（ってプログラマーの事）視点から
使いやすく設計されてるので、APIやハンドルがどうなってるのかあまり
気にしなくても使えるために純粋に作りたい処理の記述に集中できるから
やっぱり楽。
そういうライブラリに慣れてしまうとMFCは昔のCとアセンブラくらい違うなぁ。

＞４
ＡＰＩの勉強ができる方が、プログラマとしては有益でしょ。
ライブラリの力だけでは解決できない場合は、APIを直接叩く
ことになるし、ラッパーは薄い方がありがたい。

ＶＣＬとＭＦＣって比較の対象になるの？
ＭＦＣってフレームライブラリじゃん。

>>5 開発効率が悪いのは、他の全てを相殺する。

＞HG名無しさん
うーん、なるほど。
自分はまだドキュメント/ビューアーキティクチャってやつがよく分かってないので、
なんにも言えませんが、このアーキティクチャに対する批判はよく聞きますね。
相手にするのが楽しみです（笑）

＞３さん
ありがとうございます。
まだ１ヶ月くらいしか触ってないんで、正しいのか正しくないのかは
自分でもよく分からないのですが、ある程度の実績があるっていうのは、
開発でご飯を食べるものにとってはやっぱり大事ですよね。

＞４さん
そうですよね。
手元にあるMFCの参考書によると、CWndクラスなんかは
あくまでAPIの薄い皮として設計されたみたいなので、
APIとメンバ関数の名前がほとんど同じだったりしますし。
まあ、C/SDKで書くよりは分かりやすいでしょうね。
恐らくこういうのはみんなインライン展開されると思われるので、
実行効率もC/SDKと変わらないでしょうし。

MFCよりも高水準な開発を望む人に対するMSの応えが
VBだったりするんでしょうか（笑）
一度、先輩社員がVBでお作りになられたプログラムを
自分がかわりに、お客さんの前でインストールをしたのですが
「***.DLL を上書きしてもいいですか？」とかいう
（自分にとっては）わけのわからない確認ダイアログが
でてきて、お客さんに、「あーそれ上書きしても大丈夫だよ。たぶん」といわれ、
冷や汗ダラダラ、プライドずたずたって感じでした。

こういう経験から、VBはあまり好きではないので（自分用のちょこちょこっしたものを
書くのには重宝してます）、より抽象化の進んだVCLもそのうち使ってみたいと思っています。

こまかい事だが「先輩がお作りになられた」はやめようね。新社会人がよくやる間違いだよ。

>９さん
ごめんなさい。

「Option Explicit って書いとくと便利ですね」とそれとなくアドバイスしてやってんのに
P6U_BNPRとかいうバリアント型のわけがわかんない変数をコメントもなく平気で使うくせして
人の書いたものに対して、「これ、センスがないね」と平気で言うような、今すぐ脱サラして
たこ焼き屋さんにでもなったほうがよいと思われる、勤続年数だけの使えない
先輩気取りの糞社員プログラマ（名刺には「システムエンジニア」って書いてあるんだけど、
僕にはさっぱり意味がとれません)が書きやがった

とでも書いたほうが分かりやすかったでしょうか。

GetDocument()じゃないのか？

GetDocumentの返り値をキャストしないと使えないでしょ
キャストする為にはCDocの派生クラスのヘッダー読み込みが必要でしょ
（その為にCViewのソースに手を入れないといけない）

CView内（GetDocument)で変更するんじゃなくて
CDoc派生に変更内容を渡して、CDoc内でそれを実際に変更する
仕組みが無い訳よ（逆にDoc側からViewの変更(UpdataView）はこーいう仕組みになってるでそ）

CDoc派生してUpDateDocument()とか実装して、更にその派生で
アプリの用の派生CDocを定義すれば良いんだけど、、、
って欠点と言うほどでもないかも？（藁

>>12
＞（その為にCViewのソースに手を入れないといけない）
GetDocument()は普通自分で作ったCViewからの派生クラス内で作っておく
ものだが……。アプリケーションウィザードで作った場合は、最初っから記
述されているはずだけどな。
ただし、最初っから書いてあるのはCDocument *を返すようになっているの
で自分の作ったCDocumentの派生クラスのポインタを返すように修正する必
要はあるけど。
CDocumentの派生クラスのヘッダファイルをインクルードしなければならな
いのはその通りだけど、そんなもの派生Viewの.cppと.hに１行ずつ追加す
るだけじゃん。（面倒くさかったら.hだけでもいいよ）

なんか、クラスのメンバを直接いじらないとならないのが
気分悪いように思う。m_wndとかって直接さわっていいもの？
getWindowHandle()とかってしといてくれないと不安。
みなさんはどうなんでしょう？

>>13
それは、View、Docが１対みたいな場合でしょ
自作のOpenGL表示＆編集用のCOpenGLView　とかを貼り付けてたときはどうよ？

COpenGLView自体は完全に出来上がってるのに
OpenGLアプリ作るたんびに、#include＆GetDocの行を書き換えてから使うなんて変じゃん？
逆にCOpenGLViewがupdateされる度に全アプリの該当行変更するの？？
（ローカルに古いバージョン入れたままとか駄目）

後、ソース書き換えが必要だと、DLLにできないよね

＞自作のOpenGL表示＆編集用のCOpenGLView
間違えていたら申し訳ないが、もしかして、CView派生クラスの中でデータ管理を
しようとしていないかい？例えば座標データとか、そんな物をCView派生クラスの
中で管理していない？

＞COpenGLView自体は完全に出来上がってるのに
＞OpenGLアプリ作るたんびに、#include＆GetDocの行を書き換えてから
＞使うなんて変じゃん？
　普通、アプリ用のViewを、COpenGLViewから派生させて作ると思うけど。

ごめん、sageることはないよな

よくわからんが、
COpenGLViewというのは、そもそもCDocument派生を使って
いたのですか？
だとしたらCDocumentごと持ってきてDocTemplate作らなくちゃ
いけないような気がするし。
そもそもCdocument使ってなければ、#includeとか
いらないよね。

ほえ？　COpenGLViewはエディット用の窓ね、で頂点移動とか編集作業した場合
Documentに保持してるデーターをどうやって変更するわけ？

マウスで頂点移動するのはViewの範疇でしょ。でその結果を
Docに通知するのにスマートな方法がないって事よ

＞普通、アプリ用のViewを、COpenGLViewから派生させて作ると思うけど。

OpngGLViewは部品として作ってFormviewに貼り付けるでしょ
セパレーターとかで切る事考えたりすれば、部品化する方が正解だと思うけど？
あと、1画面（１アングル）で作っておけば、それを４つまとめたり（いわゆる３面CAD＋パース）するのにも便利だと思うんだけどｆ

ちょとスレの話題から脱線気味でスマソ

なんかはじめに戻ってしまうが、
GetDocument()だとまずいのかな？
View内でやりたくなければ、Document側に実装すれ
ばいいような。

ごめん、何もわかってないかも->僕

＞ほえ？　COpenGLViewはエディット用の窓ね、
ならいい。こっちの勘違い。ごめん。

＞で頂点移動とか編集作業した場合 Documentに保持してるデーターを
＞どうやって変更するわけ？
だから、GetDocument()

＞マウスで頂点移動するのはViewの範疇でしょ。でその結果を
＞Docに通知するのにスマートな方法がないって事よ
うーむ。GetDocumentがスマートではない、という事か。
しかし、CDocumentとCViewの関係は１対多になるから１２で言っていた
UpdateDocument()みたいな関数って実際CDocumentの派生クラス内で使お
うと思ったら、実装がややこしいだけだと思うけどな。

うむむ、戻ってしまうが、折角汎用的な部品COpenGLViewを作っても
ソース書き換えが絡んでは、ライブラリ化ができないじゃないかぁ〜〜
オブジェクト指向になってないよ〜

>>24
だから、アプリで使うときは派生させればいいじゃない。

＞１４さん
すいません。僕、１で、「ウインドウハンドルを 公開メンバにしてあって」なんていう知ったか君をしてますが
m_hWndを簡単に書きかえられてしまうというのは盲点でした。
ためしに、ダイアログのOnInitDialog()のなかに、
m_hWnd = NULL;
とやってみましたが、見事に落ちました。
当然、ウィンドウの外部からもこれをやってしまう可能性があるわけですから、
「MFC恐るべし」って感じですね。なるほど、勉強になりました。

＞２さん
自分もよく分かってない可能性があるので、間違ってたらごめんなさい。
２さんも、
＞CDoc派生してUpDateDocument()とか実装して、更にその派生で
＞アプリの用の派生CDocを定義すれば良いんだけど、、、
と書かれていますが、たぶん、

1.(CDocument派生ではない) CAbstractOpenGLDocument とかいう抽象クラスをつくる。
2.COpenGLViewでは GetDocument() で得たポインタを CAbstractOpenGLDocument* にキャストして操作する。
3.COpenGLViewに操作される可能性のあるCDocument派生クラスは、CAbstractOpenGLDocument を継承する（CDocumentとの多重継承）
という方法で解決可能ではないでしょうか。

JavaのInterfaceみたいなものがあればそれにしたいですけど、C++の欠点ということで。

でも、こういうキャストって出来るんですか？出来るとしても気持ち悪いですし、
どっちにしろ、２さんの言うとおり、あんまりスマートではないですね。

結局、MFCってメソッド名前のつかけたがぐちゃぐちゃだし、いまいち。
24が言ってるみたいに、スマートじゃないよね。

今からやるならATLの方がいいんじゃないとか思うが。

>>26
ＭＦＣっていうか、CObjectの派生クラスって多重継承できないんじゃ
なかったけか？
それが出来れば非常にありがたいこと、この上ないのだが。

そうかも（藁　と一瞬思ったけど
先に書いたように、OpenGLViewを４つ集めたOpenGL4Viewなんて
独立したクラスを作って、それもライブラリ化してる場合、上手くないじゃない？

GL4ViewをGLViewから派生するとどうだろ？
（むむ、混乱気味。でも殆ど中身が変わるから派生って感じじゃない？）

>>25　です

>うぃんごさん
そうなんですよ、メンバのpublic化ってのは僕の中では
「カプセル化」に反する内容だと思ってます。（一般的には、ですが。）
例えば、代表的なメンバ、m_widthとかを作ったとき、
widthの設定 : m_width = n;
widthの取得 : n = m_width;
という方法でOKなら問題ないのですが、ウインドウとかだと
設定はsetWidth()とかにする必要があるはずです。
「ウインドウの幅を変更する」にはメンバの更新以外にも
様々な処理が必要です。
また、将来的にm_widthと同時に、m_lengthを内部的に
合わせなければならなくなったときとか、メンバを直接
いじるのは非常に困ると思います。

ならばsetWidth()、getWidth()というメソッドでやりとり
するのが正しいし、将来的にも「幅の設定、取得」という
意味での予約ができるため、「カプセル化」というのは
このようにすべきではないか、というのが経験上の鉄則です。

オーバーヘッドが気になるならば、この程度のものは
インライン関数にしてしまえばいいし、メンバはあくまで
内部で処理、確実に意味を持ったアクセスはメソッドに
するべきでしょう。

ということで僕はMFCは使わないことにしました。
もちろん理由はこれだけではないのですが。

＞２８さん
CObjectの派生クラスの多重継承はできないようです（ってよく分からない文章ですね）
26の例でいうと、CAbstractOpenGLDocumentがCObjectの派生クラスだと、うまくいかない
みたいです。

あと、MFCの実行時型情報なんかの関係で、めんどくさいことがいろいろとあるみたいですが、
僕にはよく理解できませんでした（笑）
MSDNの「テクニカル ノート16 : MFC における C++ の多重継承」
が参考になるかもしれません。

すいません。普段ゲーム作ってるんで速度優先の名目で
直接メンバいじりまくり、つーか全部Public（笑）な感じなんですが

他の仕事ではもっと厳密で、無意味なpublicとかあると笑われちゃうんでしょうか？

＞１４さん
たしかにそうですね。
「おいおい、ラッパとかいっていちばん大事なとこを全然ラップしてねーじゃねーか」
とかって、MSに殴り込みをかけたいです。マジで。ウィンドウハンドルを公開メンバに
する必要が何かしらあるんでしょうか？？？

＞ということで僕はMFCは使わないことにしました。
＞もちろん理由はこれだけではないのですが。

そこのところを出来ればお聞かせ願いたいです。
このスレッドのメインテーマですので(笑)

>33さん
いや、僕もゲームプログラマです。
あくまで商品として、信頼性も要求されるライブラリとして
見るとMFCはお粗末だ、ってことです。
閉鎖している環境でのライブラリだとかはpublicで
全然問題ないでしょう。皆が承知でやってるなら、ですが。

ツールとかで長く使う可能性のあるライブラリ
なんかはなるべく隠蔽したほうがいいと思ってます。
先に書いたように、「ある意味を持ったアクセス」の
処理が大幅に変更される可能性がありますので。

＞３３
僕も普段（というかC++で書き始めたのは１ヶ月前）は自分のクラスのメンバ
ほとんどをpublicにしてしまって、心の中で「それ、classじゃなくてstructって書いたほうがいいんじゃないの？」
なんていう一人突っ込みをいれているクチなんですが、少なくとも、あくまで少なくともですが、
他人に使ってもらうようなクラスは、隠すところはしっかり隠さないと笑われてしまうというのは
一般社会と同じみたいです。

他の人に、「このメンバ、なんでpublicなの？」と聞かれたときに、
「速度優先で…」なんていうと、陰で笑われてしまう可能性は否定できないと思いますが（笑）

>うぃんごさん
他の理由は、やっぱりdoc-view構造の押し付けです。
概念は崇高なんですが、実際にはそんな綺麗に物事は
片付かないことのほうが多いです。僕の技術不足なのかも
しれませんが。

あまり深く学んでないんですが、皆さんが議論したような感じですね。
先の例だと、例えば3Dモデラ。直接的な操作は全て
viewウインドウに通知されます。つまり編集している
内容、docそのものはviewと密接であるべきなのに、あえて隔絶されている。
viewはあくまで結果を表示するだけ、という概念で
doc-view構造が作られているようにしか感じられなかったんです。
なんか、概念だけが先行してるんですね。

同時に、メッセージの流れが必要以上に複雑で、
様々な状況で場当たり的に覚えた方法でしか対処できません。
メッセージハンドラを処理する以上、メッセージの流れ、
処理順を把握しないとまともな処理ができませんよね？
なのに、それを調べるのはMSDNだけでなくソースを読んだり、
結局Windowsのメッセージ処理そのものが理解できてなければ
なりません。


もうひとつは、僕はUNIXから入ったため、Motifを学んでいました。
あくまで個人の趣味だとは思うのですが、厳密に
ウインドウ：ダイアログの役割が分割されているGUIの作法が苦痛
なのです。WinAMPなんかは明らかにそういう構造のGUIでは
ないですよね？MotifではWindowsでいうコントロールはすべて
子ウインドウと同列の扱いで、メインウインドウに貼ろうと、
どのように扱っても正しいんです。「ダイアログ」というのは
ただのポップアップで開くという「状態」でしかないんです。

Win32APIなら、推奨される方法ではないけど、こういう使い方もできます。
が、MFCではかなりやりにくいことのように感じました。

ただのラッパにしてくれればよかったんですが、
クラスに必要以上な概念を加えてしまったために
無駄に制限を作ってしまった、悪意あるライブラリに思えます。

長文失礼しました。

>14
Doc−Viewは崇高でもなんでもないでしょ｡
データの物理フォーマットと表現の切り離しはデータの汎用利用
（要するに楽をする）のに必要で、どの世界でもやってることだよう｡

DBの3層スキーマしかり、ネットがらみでデータのXML化しかり。

DBの3層スキーマってなんすか。

「MFCインターナル」というMFCの内部実装解説本があるんだが、そこに
MFC設計者のコメントがあって

「最初はOWLみたいな(とは書いてなかったが)抽象的なライブラリに
するつもりだったんだけど〜、実際作ってみたら遅くて使い物になら
なかったし〜、細かい事できなくて不便だったんで〜、それ捨てて
利便性追求型の今のMFCの形で作り直したんだよ〜」

とか書いてあった。まぁ当時のCPUパワーとか考えるとわからなくも
ないが、CPUパワーが十分になった現在では、醜い設計がきわきわに
目立つようになったよなー

CSocketとか、Win3.1時代の苦し紛れの仕様を今でも引き継いで腐っ
てるクラスもあるし。でもATLではまだまだ面倒くさすぎるんだよね。
# そういう意味でもこれからはC#/.NETにして行きたいんだろうが

ちなみにAFXというのは当初のチーム名称だったそうな。
MSのX好きは結構昔からなんだな。

>データの物理フォーマットと表現の切り離しはデータの汎用利用

いや、MFCはそれ以上（以下かな）の「何か」がしたいんじゃないかな。
何ができるのかは知らないけど、MSを擁護したつもりで「崇高」と
表現してあるだけです。

>>41
特に「何か」というのはないみたいっすよ。MFCインターナル読む限り。

自分的にMFCのいやなところはグローバルデータの
管理法が全然見えてないって事かな、_afxThreadState
とか、全然説明ないし。

>40さん
まあ、やっぱりそうなんでしょうねえ。

しかし、あの構造を無理なくしっかり使って、
高級なGUIを装備したアプリケーションってあるんでしょうか？
いや、皮肉って聞いてるんではないです。

＞１４さん
やっぱりDoc-View関連の問題ですか。
ここのところは自分はよく分かってないので、もう少し勉強して
何らかのコードを書いてみてから考えてみることにします。

38さんの言う通り、データと表示の分離っていうのは
実際自分も（いわゆる制御系ってやつですが）
自分で一からプログラムをする際に常に考えてることですし、
どこの世界でも使われている技法のようなので、
そんなに悪くはないと思うのですが。。。

メッセージの流れのほうも、どうも、Chain of Responsibilityとかいう
パターンのようなのですが、これも自分はよく分かってないので
もう少し勉強してみます（笑）すいません。

＞ただのラッパにしてくれればよかったんですが、
＞クラスに必要以上な概念を加えてしまったために
＞無駄に制限を作ってしまった、悪意あるライブラリに思えます。

そう言われてみれば、「押し付けがましい」ような気もしますね。

＞長文失礼しました。

いえいえ、なんだかいっぱい書いてくださったのに、勉強不足なため、
きちんと理解できなくてすみません。本当にありがとうございます。

＞４０さん
あ、それ僕が書いた本です(笑)
まだ謝辞までしか読んでませんけど。

Doc-View構造は、どうも、ActiveX/OLEにつながっているような予感がします。
たとえば、Wordのウィンドウの中で、Excelのデータを表示/編集できるっていうのは
Doc-View構造の賜物って感じがしませんか？

OWLってそんなに遅いっすか？

>>46
ん? 俺の事かな?
実際に本の中でOWLが引き合いに出されてた訳じゃないし、俺はOWL使った
事ないので速度は知りません。巷で「OWLはほどよく抽象化された良い設計」
と評価されてる事が多かったんで、俺が勝手に引き合いに出しちゃいました。

# にしちゃ書き方がちとまずかったか。悪意はないです。

むきーあげ

ＯＷＬ全然遅くないっす。
ＯＷＬ派っす。

タブコントロールに貼り付けるダイアログ
(CDialog派生でClassWizardに生成させた)、
各タブ(ダイアログ)に共通の処理インターフェースを
持たせたくて、

class EachTab {
public:
　virtual void methodA() = 0;
}

というインターフェース定義のクラスを作り、
各タブ内容のダイアログを表す各クラスを
class TabA : public CDialog＠｀ public EachTab {
public:
　void methodA();
　/* 以下ClassWizardが作成した何やかや */
}

class TabB : public CDialog＠｀ public EachTab {
public:
　void methodA();
　/* 以下ClassWizardが作成した何やかや */
}

という風に手作業で書き換えた。
呼ぶ方で、

// CDialog *tabs[N]
for (int i = 0; i < N; i++) {
　((EachTab*)tabs[i])->methodA();
}

呼ばれない、吹っ飛ばない、アサートダイアログもでない、
ただ呼ばれない。
なんでだ〜

むー、中間にもう一段派生させ、多重継承はそこでやらせるようにしたら
望み通りに動いた。

class _EachTab {
public:
　virtual void methodA() = 0;
}

class EachTab : public CDialog＠｀ public _EachTab {
　// まだ抽象クラスのまま
}

class TabA : public EachTab {
public:
　void methodA();
　/* 以下ClassWizardが作成した何やかや */
}

// EachTab *tabs[N]
for (int i = 0; i < N; i++) {
　tabs[i]->methodA();
}

なんでだ〜

>50
お、MFCのワナにはまったみたいっすね。
それぞれのクラスがどういうふうにインプリメントされているか
まったく仕様を明らかにしていないので、公開された
メソッド以外の処理は手探りで探すか、場当たり的に
とりあえず動いたコードでどうにかするしかない、ってやつ。

なまじ抽象的な概念をクラスに加えすぎると、
必要以上に複雑で、理解できないし応用もまったく利かない
パーツが出来上がってしまうっていう代表ですね、MFCは。

今日はMFCを酷評します。

ソースが公開されていることを知らないヤツがいるな・・・

>>53
52読んで？？？って思ってたんだけど、やっぱそういうことなのかな。
でもデバッグしてればMFCのソースにはただりつくしなあ。

ＭＳの一存で仕様が変わるのはちとこわひ。

全部は公開されてないのでわ

>>54
「手探り」ってのがソースを読むって事かなあ、
と好意的に解釈していたんだけどな。

>>56
全部公開されてるよ。つーか「回避不可能なバグがあったらてめーで
パッチ当ててリビルドしろ」ってのが何回かあったし。DAO周りとか。
srcディレクトリの中にmakefileもあるっしょ。

>「手探り」ってのがソースを読むって事かなあ
いや、その通りっすよ。
>52
「ソースを公開」＝「仕様を公開」ということではないでしょう。

間違えた。
>53
です。

14さん
ソースはあるし、使い方を示したヘルプもある。クラスツリーもある。
あと「仕様を公開」するにあたって足りないものって何でしょう。
＃最近はUMLで図を揃えないとドキュメントとして認めてくれないのかな…

すみません、sageてしまいました。

がいしゅつかもしれんけど、MFCはMFCの機能の範囲内
で使うぶんには便利だし楽なんだけど、そうじゃない
事しようとするとコード書いててばからしくなる。

俺はＣ言語＋SDKしか使わなくなっちまった。
１度書けば使いまわしできるモノが多いんで、MFC
に対して極度に面倒って事もない（最初の１回が
面倒なだけ）。

新しいコントロールの使い方はMFCのソースから
パクるので無くなると困るが。

MFC使うのは、ActiveXとかのSDKからは面倒すぎ
るモノ使う時だけ。（且つVB禁止の時）

>54さん
すみません、間違ったことを書いたらあやまりますね、先に。

どちらかというと、MFCの都合上の問題でそうなのかもしれませんが、
例えば強引なキャスト変換。あたりまえのようにサンプルとかでも使われて
いますが、本当にそれでいいのでしょうか。具体的なのは忘れましたが。
Doc-Viewといいながら、EditViewなんかはViewにドキュメントがうめこまれて
いるのですがそのことは、どう説明されているのでしょうか。

というような、不安要因となる部分に関してはしっかりと
明文化しておくべきでしょう。
「仕様の公開」とはそういった類をしっかりとオープンに
しなければならないと思います。
「ソースの公開」によってそれを行うのは、ただのサポートの
放棄ではないでしょうか。というのが僕の考えです。

あるクラスで、publicなAというメソッドを実現するために
privateなBというメソッドを内部で使うとしましょう。
ユーザーがA相当のことを行うために、このB相当のコードを
使ってしまうことが許されるでしょうか。
将来、Bだけでは足りなく、Cというメソッドも必要になったら、
ユーザーはこのクラスがバージョンアップされたとき、
privateな変更に対して対処しなければならないです。
これは「クラスのカプセル化」が破綻しています。
ソースを参考にしてプログラムを書くというのは
こういう部分もあるので、それを当たり前とする
文化はクラスライブラリにとっては致命的だと思います。

とりあえず、Motif、C++Builder、MFCで開発したことが
あるのですが、ソースを読まなければならないのはMFCだけでしょう。
揚げ足をとるつもりではないのですが、そういう事態が
当たり前になっていること自体、MFCの酷さを表しているように
感じられます。

63さんのいうように、「MFCの機能の範囲内」で限定すれば
扱いやすいライブラリなのかもしれません。
僕が明らかにイリーガルなことをしようとしていただけかも
しれませんね。「Win32SDKのラッパー」という希望を
持って使ってみたのが間違いのような気がしてきました...

前に言ったこととは矛盾している部分があります。
内容を知らなければならない点、知らないほうがいい点
というのがあります。
知らなければならない点、とはフレームワークのような、
OSの都合で制御順などに影響を受ける部分なんかです。

>>64

ドキュメントがビューに埋めこまれてるなんて感じた
事無いなぁ。関連付けられているって程度じゃない？
っても、VC++2.0以来MFC使ってないから忘れた。

茶々だけど、C++BuilderのVCLのソース読む必要って、
けっこうあったよ。VCLにバグが多いから、変な動き
したらソース追うんだな。

OSF/Motifのソースは見た事ないけど、あれはクラス
ライブラリじゃないからな。単なるウィジットセット
だし扱いもアテナウィジットに毛が生えたようなもん
じゃん。MFCやVCLと並べるようなモンじゃない。

Lesstifはソース見るしソース修正もするよ。だって、
Motifと非互換な所に限って移植元のプログラムが使っ
てるんだもん。日本語の問題もあるし。

>66
>あれはクラスライブラリじゃないからな。
そうですね。前提として、僕はフレームワーク用のライブラリ
としてみなしての発言です、全部。
そういう意味では確かにMFCやVCLとは全然違うものですね。
だからMFCは、僕にとっては異常に見えるんだな。

ごめんなさい、Builderは確かに変な動きすることあるね。
どうこう言えるほどしっかりとは触ってないや。
勿論Builderを推奨してるつもりもないです。
僕はWindowsではWin32APIがメインです。

>>67

＞僕はWindowsではWin32APIがメインです。

それで正解。

CStringはchar*やstd::stringより便利だけどどう？

>>69
別の環境にもっていけるような部分では、CStringは使いたくないな。
ＭＦＣと心中してもいい部分だったら、別にいいんだけどね。

>>70
同意。しかしSTLも微妙に実装に差があるようで(VC++のSTLってメンテされてないし)
いまいち安心して使えないんだよなー。

>68
やっぱり？
>71
実装によって違うのは困りますね。
実際、どのSTLの実装で違いがあるんですか？

>>72
あまり詳しくないんだけど、
HP
SGI
STLport
Rogue Wave
Dinkumware
とか色々あるみたいよ。

モデナ社とかいうのもあったような。

>73
そんなに派手に候補があるなんて、STL全然標準じゃないですね。
気にせず使ってたんですが、けっこうヤバイですね。
さらに具体的に、どういった部分が違うかまで知ってます？
あるいはその辺りに詳しいサイトなんか知りませんか。

凝った使い方しなければ大丈夫じゃない？

まあ、実際に気づかなかったぐらいの使い方しか
してなかったから、そんなに気にしないでいいのかも。
ただ、本当に忘れた頃にバグでも出たら気分悪いあたり
なんで怖いですね。

とりあえず配布元のURLを。

http://www.sgi.com/Technology/STL/
http://www.stlport.org/
http://www.dinkumware.com/
http://www.roguewave.com/

HPのはどこかのFTPサイトにあったきがするけどわからない。

STLportはSGIのを色々な環境にportしたものらしい。
ダウンロードしてみればわかると思うけどMakefileの数が多いのよ。
私は、VC++6(SP3)とC++Builder4(SP1?)とLinuxのegcs1.xの環境で
Makeできたよ。portというだけあるね。

ありがとう。僕も気になるので調べてみます。
それにしてもSTL、詳しそうですね。

http://sources.redhat.com/libstdc++/
こんなのもみつけた。:-)