・休みだよん。まー毎週のことよ。

・今日もお休みですー。あ、そうそう、プログラミング辞書の単語追加申請を来週から開始するんでそんときはよろしくっ！

・今日もお休みです（汗）。今週もしかしてずっとお休み？（汗）

・今日はＣマガを買いました。ここ最近は特集を３つくらい用意することが多いですねー。実際、１冊の本として出すにしては量が少ないテーマは、こーゆー形で雑誌で取り上げるのが一番かも。手当たり次第出して「当たり」があれば連載に持っていけばいいわけだし。
　
・第１特集で iostream と STL が出てきましたねー。ここで std::map を iostream に渡す時にうまくいかないとか書かれてるけど、実際にはそんなことないです。これは直接渡すから問題なんです。コンテナを iostream に渡す時は、 iostream のイテレーターを std::ostream_iterator に入れて std::copy() に渡すのが基本だと思うです。これを基本形にすれば、カスタマイズの方法はいくらでもあるわけです。
　
・たとえばカスタムイテレーターを作る方法。 std::map のイテレーターは std::pair を返すけど、これを std::pair::first と std::pair::second を別々に返す、つまり std::map が倍の要素を持つかのように見せかけるイテレーターを作れば問題なし。あとはこのイテレーターを std::copy() に渡せばＯＫね。 std::ostream_iterator は区切り文字を指定できるから。あーでも、これだと std::pair::first と std::pair::second が同じ型でないとダメか。
　
・じゃーこの応用として、カスタムイテレーターから、 std::pair と区切り文字を持つ特別なクラスを返して、別にこの特別クラスと iostream 用の operator << を作っちゃうとか。これはかなり汎用性高くなります。カスタムイテレーターを作るときに first と second の区切り文字を指定して、それを特別クラスに持たせて、 operator << 内で first と second の区切り文字に使って、次のデータとは std::ostream_iterator の区切り文字で区切る、とかもできます（でも実際に試してないからなんか問題あったりして（汗））。
　
・重要なのは std::copy() と std::ostream_iterator 、つまりアルゴリズムとイテレーターという存在を知ってるってこと。これを知ってないと、 iostream をアルゴリズムやイテレーターで処理するってゆー考えは起きないでしょ。でもこの発想があれば、ワンクッションおけばいいってゆーことが分かるわけ。実際、標準 C++ ライブラリはまずこのアイディアを提供してくれるってことが大事で、それを支えるライブラリはある意味二の次、かも。
　
・まーもしかしたら、そこまで大風呂敷にしちゃうと話がまとまんなくなっちゃうから、こーゆー話にしたのかもしんない。正直なところ、標準 C++ ライブラリは全体を見渡せないとこーゆーことに気付かないから、それがデメリットではあるんだよねー。わて自身、かなり敷居は高いと思うです（ STL & iostream 入門でなんとか下げてるつもりだけど）。でも「だから MFC 」ってのは（汗）。この仕組みを知ってれば、 MFC の資産も生かせるしね。
　
・でわまたっ！

・昨日の例を試そうと思ったんだけど、途中でめんどくなった（汗）。ってゆーのも、イテレーターを１から起こすのは結構大変ってゆーのがあるんです。とりあえず雛形作って、それを使い回せばいいんだけど、逆にそうなると、雛形をしっかり作らないとあとでとんでもない目に遭うんで。
　
・もちろん継承を考えて作ってもいいんです。たとえば iostream みたいに、イテレーターの operator 部分と、実際に処理する部分を分けたりとかして、処理部分はポリモーフィズム化できるようにするとかね。でも、イテレーターって繰り返し呼び出す部分だから、そーゆー構造にすると積もり積もってかなり時間食っちゃう可能性があるわけです。その辺がね。 STL でそういう構造になってないのは、たぶんそーゆーのがあるからなんじゃないかなー。
　
・ただ、簡単なテスト用にはこーゆーのは便利。たとえば昨日のなんかは、 std::pair を他のクラスに変換する部分さえあればいいんだから、そこの部分をオーバーライドできるようにしとけばテストが楽にできるわけですね。そのためにも、 STL や iostream を再利用しやすい環境を作るかなぁ。
　
・あーあと、ぷらとわを２話作りました。今日作ったのはコードが多かったんで結構早く終わったなー（汗）。この２話は、リストボックスの使い方と、配列について。なんか順番ぐちゃぐちゃだなー（汗）。次は文字列について書こう。それはテストのあとだなー。
　
・今日のお便り！

・どうもですー。Ｃマガがウィンドウズ寄りになったのって、結局インサイドウィンドウズが廃刊になったののあおりなんですかねー。プラットフォーム非依存っぽいのに、雰囲気的にウィンドウズ寄りな感じが（汗）。わて的には Mac 関係の記事が増えて欲しいんですけどねー。そんなにマックプログラマーってのはいないんだろうか（汗）。あとちょっと宣伝。 STL & iostream 入門でも streambuf のカスタマイズやるんで読んでねん。あーでもわての方だと traits まわりは省いちゃってるからあれかも。
　
・でわまたっ！

・初めにお知らせ。明日はお休みしまーす。では今日はお便りが２通来てるからその紹介を。まずひとつめ。

・どうもですー。型の部分はどうなんだろう、 C++ の typeid みたいなランタイムなものなのか、それともコンパイラが全変数を追ってくれてコンパイルタイムに決定できるのか。これってかなり重要なんで。わては後者の方がいいなー思うし、 C# のドラフトを読むと後者っぽいんだけど、それってえらい大変な気もするし。コンパイルに時間掛かりそう……。
　
・その他にも、件のページを見るとなんか謎なことが結構……。たとえば「 VS.NET ではどの言語で書いてもクラスは COM コンポーネントになる」とか（汗）。それってつまり C++ で書いてもゆーことなんかなぁ。まさか１クラス１ DLL ってことはないと思うから、逆に Exe 内のクラスを外から呼び出せるゆーことなんかな。こーゆーシステム自体が .NET のウリで、それに VS が利用されるってことらしいです。なんだかなー。まーでも、それなりに需要はありそう（爆）。うふふ。
　
・もひとつお便り。

・あう〜、そんな落ち込まないでくださいですー。わてが思うに、プログラミングを理解してることと、それをまとめて文章化することとはやっぱ別ですよ。しかも、商業誌ってゆーえらい制約があるわけですから。わてだって、 STL & iostream 入門を本として出したかったのにぃぃぃぃ（泣）。まー無料のメルマガで１８００しか購読登録されなかったんだから、出しても売れなかっただろうけどぉ（苦）。
　
・あう、 std::for_each() の戻り値が関数オブジェクトだって初めて知った（汗）。奥が深い。実際の所、 STL は「可読性」という点で、非常に微妙なもんだと思います。この例だと for を std::for_each() に置き換えたことで「意味づけされる」というメリットが、メンバ関数ポインタの呼び出しと結果の出力っていう部分の分かりにくさに相殺されてるんですよねー。これなら素直に for 使った方が解りやすいかもしんない。
　
・ STL も iostream もカスタマイズが命だけど、カスタマイズが逆に可読性を落とす可能性もあるし。それに既存の関数とかでも、アルゴリズムとか膨大だから知り尽くせない部分もあるし。可読性が上がるようにするのなら、プロジェクト全員が標準 C++ ライブラリを知り尽くして、カスタマイズクラスは徹底的に汎用性を上げたものをプロジェクト全員が共同で使用して、ってしないとあかんです。で、それをするには標準 C++ ライブラリは敷居が高すぎます（泣）。
　
・中途半端に使うとかなりまずいし、いっそのこと触れない方がいいのかもしんない。他言語に活用できないしさ……。
　
・でわまたっ！

・予定通り、この日はお休み。

・はっ、今日もお休みだ（爆）。

・一応お休みだけどちょっとだけ。プログラミング辞書の単語、思いの外送信数が少ない（汗）。しかも大半がすでにある単語（爆）。もうかなり単語が揃ってるってことなんかなー。でも休止前は、新しい単語もかなり来てたし、もちっと待ってみましょう。
　
・でわまたっ！

・とある所で多次元配列について訊かれたんでちょっと調べたりしました。ってゆーかすげー使いにくいんですけど（汗）。ポインタにキャストしてごりごり操作した方が楽そうだなー。もちろん C++ なら std::vector 使って処理しちゃうけど、これ訊いた人は初心者さんだし開発環境が C オンリーみたいなんで。
　
・普段使わない上にちゃんとしたドキュメントが手元にないんで分かんないんだけど、 int iAry[2][3] 全体を操作するためのポインタは int (*pi)[3] = iAry ってすればいいんだよね。配列をポインタに移すと配列のサイズが分かんなくなっちゃうから、こーしなきゃいけないのかな。
　
・なんか混乱するなー。メモリのイメージを考えると、リニアに全要素が並んでるんだからポインタのポインタになったりするとことかかなり混乱するです。やっぱ std::vector を要素に持つ std::vector で２次元配列作った方が楽そう。まー配列ってもんは使えない上に複雑過ぎるってことなんかな。でも std::vector も複雑か。
　
・ C++ やってると「組み込まれてるよかコードのあるライブラリの方がいい」とか思うけど、そーゆーのはあかんのかなー。たとえば「文字列型」とかなんか使えなさそうなイメージがあるのは何故だろう。それよか「配列か std::string か CString か」みたいな感じがある。そーゆーのってあかんのかなー。
　
・でわまたっ！

・今日はお休み。

・テストが終わったよーん。とゆーわけで、これからのプログラミングの予定。
　
・まず、フリーウェアのマイナーバージョンアップをします。これまでは「完全 KTL 化、脱 MFC ！」を目指してたけど、これは現実的に不可能な気が（泣）。なんで、 MFC ベースで少しずつ KTL 化する……雰囲気（？）で、それに伴って細かい部分のバージョンアップを行います。特に全フリーウェア、バージョン情報の URL とメールアドレスが引っ越し前のになってるんで、それをしないと。
　
・あと、新しいフリーウェアを作る……かもしれない（爆）。作るとしたら、新しいフォルダ・ファイルランチャー。使うアプリだけでいいアプリランチャーと違って、フォルダ・ファイルランチャーは登録制だとまったく使えなくなっちゃいます。そこで、ファイル全体を表示するユーザーインターフェイスが必要なんだけど、それをどうするかが問題。
　
・正直、まどかぶは使えないです（汗）。フォルダ内の構造って、だいたい頭の中に入ってますよね。その場合「メニューの中から目的のフォルダ・ファイルを探す」ってゆーのだとストレスが貯まるかなと。そうじゃなく、直感的に「あのフォルダ・ファイルを開く！」っていうことができる、そういうユーザーインターフェイスを実現したいと思ってます。
　
・イメージはできてるんで、あとは、すでにそーゆーのがあるのか、そして実際に実現できるのか、が鍵かな。とりあえず夏休み中にテストバージョンを、そして今年度中にリリースバージョンを出せたらなーと思ってます。で、アプリ名を悩んでます。「ひらかぶ」にするか「あけかぶ」にするか（爆）。
　
・でわまたっ！

・今日はお便りの紹介をしましょう。では今日のお便り。

・「ダイアルロゴ」ってダイアログのことかな？　だとすると、 SetActiveWindow() でできるかな。ダイアログが前後にあって、後ろにあるダイアログを手前に持ってくるときには、後ろのダイアログを CDialog 派生クラスの変数として作ってるはずだから、その SetActiveWindow() ってメンバ関数を呼べばＯＫ。……なんか説明難しいなぁ（汗）。
　
・それ以外の事を指してるんだと、想像するだけで難しそう（爆）。ま、違ってたらまた送ってねん。これから時間的余裕あるし〜。
　
・でわまたっ！

・今日はプログラミング辞書をげしげし書いてました。ごめんなさいが追加単語の倍ある（爆）。追加単語の方も、わての方で追加したものが結構あるし。そういう点では楽だったのかもしんない。でも久々だったんで慣れない部分も。それにしても、もうすぐ４００単語……なんかすごいなー。
　
・あとこれからぷらとわ書かないと（汗）。ぷらとわはギリギリでなんとか保ってたからなー。とりあえず今日明日と書き貯めておこうと思ってます。……なんか、こーやって辞書書いてぷらとわ書いてって感じだと、わてながらすげー量書いてるなぁとか（笑）。文章書くことは全然苦にならないんですよねー。なんか謎だ。
　
・あ、あとこれからかなゆ〜も書こうと思ってます。誰も書かなそうなことを１ヶ月単位くらいで書いてきたいなとか。でも今はネタがないや（爆）。１週間の間になんか考えよう。
　
・でわまたっ！

・休みに入ったのにプログラミングしてねぇ（爆）。あ、でもぷらとわ書いたか。では今日のお便りっ！！

・のんのんのん、 const メンバ関数や関数の例外指定は、はっきし言って書いてある本が非常に少ないのです。だからある意味知らなくて当然かも。 throw() については２月１５日のを読んでね。かなりしっかり書いてあるから。あ、そうそう、 const と throw() は関係ないから。だから throw() だけの指定もあるし。
　
・ const は「メンバ関数の const 指定」です。こーゆーふーに const 付けるのは、メンバ関数に対してだけ。普通のグローバルな関数には付けられないです。で、 const をメンバ関数に付けるとどうなるかというと、その関数の中では this ポインタが const 扱いになります。上の例だと Test::parseInteger() の中の this は const Test * 型になるってことね。
　
・そうなると、まずメンバ変数が const 扱いになります（暗黙的には this ポインタを通してメンバ変数にアクセスしてることになってるから）。だから int m_i があっても Test::parseInteger() の中ではm_i = 100 とかできないのです 。同じようにメンバ変数への参照を返す場合にも、戻り値の型が const 参照でないと返せないです。 std::vector::at() に const バージョンと非 const バージョンがあるのはそのためです（これは const あるなしでオーバーロードができるってことでもあります）。
　
・また、 const メンバ関数から非 const メンバ関数は呼べません。 const メンバ関数だけ呼ぶことができます。この関係で、呼べるメンバ関数が思いっきり制限されます。 const メンバ関数にするかどうかを設計段階で決めないと、コンパイル時に死ねます（笑）。初めて自分でクラス作り始めて、そんときに const メンバ関数を使うと、いつまで経ってもコンパイル通らなかったりしかねないです。で、結局全部非 const にしちゃったり……。
　
・さらに、 Test 型変数が const な場合には非 const メンバ関数は呼べません。 const メンバ関数だけ呼ぶことができます。これが実はすっごく大きいんです。これは参照やポインタでも当てはまるからです。「関数の引数どうしよう。クラスだから参照渡しにして、安全志向で const にもしよっと」とかしたらもう大変、その関数内では const メンバ関数しか呼べない（爆）。つまり、 const メンバ関数を使用しない限り、 const 参照や const ポインタをクラスに使えないのです。
　
・要するにすごーくめんどいってことです（汗）。「このメンバ関数からはこのメンバ関数が呼べてぇ」とか考えなきゃいけないから、設計にえらい時間掛かります。ただわては、これとテンプレートがあるから C++ が好きです（爆）。これのおかげでかなり安心してコーディングできます。メンバ変数が変更される範囲をぎゅっと絞り込めるからね。とりあえず MFC や標準 C++ ライブラリではばんばん使われてるんで、そういった使用例を参考にしつつ挑戦してみてください。
　
・でわまたっ！

・今日はお休みします。