[Top]
> [Records September, 2003]
管理者：Wayne 
＿8月は終わってしまったらしい．まあそれはどうこう言うことじゃないが．というかまあむしろそっちの方が……
＿妖々夢のdatはとりあえず完全連続で24時間程度．まあ微妙なのでこれ以上はいいや．
＿一体いつの間にこんな知識と技術と道具を揃えちまったんだか．もっとも腕の程はさっぱりだが．
＿アルファケンタウリがやりたい！ と突然叫んでインストールして始めたもののかなりの序盤でとまったまま結局進んでないのは如何なものか．とはいえテクノロジーツリーとか年号がいまいち分かりづらく，現状どの程度の序盤なのかというのははた疑問．Civと違って早々に海に出て行けたり海都市作れたりはたまたレーザ打ち込んだりできるので感覚が分からないのだ．青銅器と鉄器だったら鉄器のほうが強そうだと分かるし弓とマスケット銃ならマスケット銃のほうが圧倒的なのが明らかだが，ガトリングレーザーとフュージョンレーザーと量子レーザーではどれが強いんだかさっぱりである．かっこいいのはいいんだがぱっと見てではさっぱり分からん．技術に至っては上級軍事アルゴリズムだとかＮスペース圧縮だとか知覚計量経済学だとか制御特異点だとか有機超潤滑剤だとかゼロ摩擦表面加工だとかもうねこの辺にしとくけど．頼りになるのは横につけられたゲーム的な数値だけだ．建設10とか研究12とかそういうの．だが技術のレベルが分かったところでじゃあそれを手に入れたら何が良くなるのかやっぱりさっぱりである．火薬ならマスケット銃と繋がるんだが，物質圧縮でニュートロニウム装甲では何がなんだかさっぱりではないか．
＿でも燃え．
＿まあ，いっぺん通して終わらせてみないと分かるものも分からんよな．
＿うーん．IDE欲しいなあ．C#のIDEあたりはあきらめることにしてC++だけでもまあいいんだけど，問題はコンパイラが気になるってことで．あの最適化オプションなしって表記は一体何を意味してるんだか心配で心配で．7.1はboostが全部通るらしくそういう意味でもかなり魅力的なんだけど．まあ別に今のところ困ってるわけじゃないんだけどさ．ていうかcl.exeって何か落としたらついてきたような記憶もあるんだけど何だったかなあ．
＿やっぱIDEは重要．デバッグという点でもそうだし，IntelliSenseはなんだかんだ言いながらも便利だし．あんまりにも小さいプログラムだったりするとIDEは逆に無駄にファイルやディレクトリを生成したりするということがあるので，テキストエディタでソース書いてcmd.exeからcl.exe呼んでコンパイルするというようなことが多々あるんだけど，ある程度以上のものはさすがにIDE無しでやろうとは思わないし．ところでTeraPadはC#のキーワードハイライト対応してくれないかしら．いやあんまり使わない気はするけど．
＿うーん．Normalすら終えてない奴がExtraやるなって雰囲気．狐に会うまではなんとかなるにしろ，じゃあ狐さんがどうにかなるかっていうとそんなもんどうにもならんわけで．ただExtraの場合はNormalよりも短いので，パターンを頑張って詰めていけばそれなりになんとかなるんじゃないかと思ったりもしないわけじゃなかったり．というか高速弾とかが多いのでパターン詰めて，こうやれば絶対避けれる，というようなそれが楽しいではある．Normalでも同じは同じなんだけど長いんでちょっとなあ．アドリブ効くほど基礎能力がないんで，とにもかくにもあらかじめ決めた一定の手順を追い続けることでなんとかしないとと思うのだが．基礎能力ない奴がExtra終えられるとはとても思えんな．
＿というか妖々夢で遊んでる場合じゃないような．気のせいか．
＿Phantasmお見事．曲を聴いたりゲーム中の会話見たりするにおそらくそうなんだろうなと思ってはいたが，なるほどよくできてる．まあしかし自分でこれをなんとかしようとはちょっと思わないなあ．Lunatic一周とどっちが難しいんだろう．
＿Extraばっかりやってて時々Normalとかに戻ると，FullPowerでなくてもアイテム回収ができると勘違いして画面上部に突っ込む罠が．そしてアイテム全部取り落とす．悲しい．
＿やっちまった大失敗．まあ失敗したのがゲームで良かった．やっちまったもんしゃーないので失敗は失敗なりになんかに活かさないとな．ゲームとはいえセーブとロードがないのはつまるところ取り返しはつかないってことだ．
＿ただの愚痴なので大半まとめて全部略．理不尽だ．いろいろと．
＿多分どっかひっかかるところがあるんだと思うし，実際のところそのうちいくつかは自分でもそう思う．所詮上っ面整えたところで中身が出来とらんのではダメだということなのだろうと思うが，中身をなんとかしろといってみたところで具体的になんとかできるのかというと難しい．これがダメだあれがダメだと具体的に気付く度に気をつけているつもりなのだが，長年染み付いたと言うかむしろそれで出来上がってしまったものはなかなか変わらない．自分本人の中では気をつけているつもりでも，外から見れば何も変わってなんかいないわけで，全然気をつけてなんかいないだろうとか努力が足らないだろうとか言われるに違いなく，具体的になんとかなるまで外に対してどうこう言えるだけのものは提供できない．だが死ぬまでなんとかなんかならんと思う．これは別に努力の放棄ではなくて，生きている間は永遠にダメなところを改善しようとし続けなければならないだろうという意味だ．私は神でも仏でもないし，神にも仏にもなれない．
＿なんとなく大往生をやってみたが，さすがに難しい．妖々夢をやっていたのでなんとなく出来そうな気がしていたがただの錯覚なのは当然のことだ．妖々夢プレイしたからと言って大往生のレベルが下がるわけでもなく，私のレベルが劇的に上がるわけでもない．Stage1から容赦なく襲い掛かる高密度かつ高速度の弾幕．あの徹底的に小さい当たり判定でも当たる．Stage1や2からもう既に妖々夢NormalのStage4や5くらいの難易度だったりはしまいか．大往生でStage2まで来るともうノーミスとかはまったく考えられない．ノーミスでいけるのはStage1だけだ．
＿まあ妖々夢のHardがアーケードでシューティングをやる人向け，とあるのもそれなりに納得できる．大往生なんかだとLunaticでもおっつかないくらい難しいんじゃないかと思ったりしないでもないが，実際のところどの程度の難易度調整なんだろう．妖々夢LunaticをプレイしたときStage1すら終えられなかった記憶があるから，やはりその程度の難易度調整なんだろうか？ LunaticはPhantasmより難しいのかもしれない．ていうかなんにしろスペルカード全部集めるって一体．いや，やる人はやるんだろうけどさ．私にゃ半分もいけるかどうか．
＿寝損ねた雰囲気．しかも違ったらしいし．なんだったんだ一体．
＿大丈夫だったとは思うけど，中途半端に寝てると心配ではあるな．昔からこういうときは寝るに限ると決めていたのに．でなければ完全に寝ないとか．でもそれもそれでやっぱりやばそうだ．
＿なんか問題が嫌．
＿必要なときにはケチっちゃいけない．金とか．何の話だよ．
＿妙にケチって無駄が増えてる雰囲気．なんとかならないかなあ．というか，必要なときには使え，不要なときには使うな．めりはりつけろってことですな．どこだっけどこぞの会社の社長が言ってた．まあそういうことなんだろう．
＿ありえねー．
＿アリエネー．
＿もう目の前に起きてる事実が凄すぎて信じられない．なんでこんなことできるかなというのが先走って凄いと思うより先に呆れる．こうこうこうやってやりました，と聞いてみれば確かに不可能なことをしてるわけではないのだが，それにしたって，なあ．自分には無理だ．凄い人は本気で凄いのだと改めて思った．
＿また変なの書きはじめるし．まあ私は凄くないので凄いものは出来ないけど．変な人なので変なものなら出来るかもしれんとかどうとか．
＿えーっと．なんだっけ．まあいいや，とりあえずやれることはやりましょ．色々そっちのけで．えー？
＿毎年恒例秋の風邪．喘息付き．
＿大分懐かしい．ここしばらく喘息でどうこうということはなかった気がするのだが単に忘れてるだけだろうか．まあ勘弁して欲しいが．こいつを患っていて唯一良かったのは百害あって一利しかないタバコを吸えなくしてくれたことかもしれない，などと変なことを思ってみたりもする．喘息が酷かったというか治療をしていなかった小学生の時分に体育の授業をサボる口実に使ったのかもしれないが，よく覚えていない．よしんばそんなことが出来て実際に実行していたとしても，中学高校共に普通に体育の授業は出ていたわけで，結局のところこんなものを口実にサボれるよりはむしろ普通に体育の授業の方がなんぼかマシだったのではなかろうか．
＿あとなんだっけな．まあいいか．
＿どうもたるい．喘息の方は薬のおかげかなんとか．特に強い頭痛がとかどうとかということはないがなんともいえずたるい．熱があるのかと測ってみれば36.4だそうな．
＿えーっと……
＿世の中一般では平熱って言うんですかね？ まあ体温計君が嘘をついているわけではなかろうからもし違う数値が出ているのであればそれは私の測り方が悪いんだろうけれども．ただ個人的に思うに，通常朝起き抜けで体温測る場合は大概35.9とか8とかな気がするんだが，そのう……なんだ．個人差という奴かね？ こういうのは熱があると判断すべきなのかないと判断すべきなのか分かりかねる．まあ昼間になれば世の一般に言う平熱まで上がるのがいつものことだった気がするから，このまま維持して昼になれば元気に違いない．
＿まあなんていうか，こういうときってのはやってる操作が怪しいとかいういつもと違う自分が見えてそれはそれで楽しい．怖いが．重要なファイル消してたりしなければいいが．
＿うーん．引きずっているような．
＿お願い．勝手に関連付け設定書き換えないで．ちゃんと許可を求めて欲しい．いくら起動が早くなったって言ったって1秒2秒待たされるとやっぱ遅いなあと思うんだよ．私が期待しているのは，ほぼ一瞬で起動する，シンプルで，だけど目的には十分過ぎる使い慣れたただのテキストエディタなのに．
＿64bit Windowsだとこういうことはできないのだろうか？
int CDialog::DoModal(HINSTANCE hInst, HWND hWnd, UINT nIDDialog)
{
return DialogBoxParam(hInst, MAKEINTRESOURCE(nIDDialog), hWnd,
DlgProc, reinterpret_cast<LPARAM>(this));
}
BOOL CDialog::DlgProc(HWND hDlg, UINT Msg, WPARAM wParam, LPARAM lParam) // static function
{
if (Msg == WM_INITDIALOG)
SetWindowLong(hDlg, GWL_USERDATA, static_cast<LONG>(lParam));
CDialog *dlg = reinterpret_cast<CDialog *>(GetWindowLong(hDlg, GWL_USERDATA));
if (dlg) return dlg->DialogProcEx(hDlg, Msg, wParam, lParam);
return FALSE;
}
＿要するにアレですかね，特定のアーキテクチャと心中するつもりなら以下略って奴．しかしポインタのサイズが拡張されるなら当然関数ポインタのサイズも拡張されるはずで，SetWindowLongでGWL_WNDPROCを指定して関数ポインタ書き換えによるサブクラス化をサポートしている以上このあたりは変更されてしかるべきで，だとすればUSERDATAの方だって拡張してくれていいんじゃないか．というか関数名からしてSet/GetWindowInt64とかとか．まあそれならそれでこの部分直せば動くんだろうが，むしろこんなことしてないでもっとスマートな実装方法考えろって感じはする．
＿というかreinterpret_castなんか連発してる時点で以下略．
＿引きずってるというかむしろ悪化してるような．なんか妹君も調子悪いようだし，うつされましたかね？
＿マゾいというか，さすがというか，なんかなあ．C++さまさまなのはいいが，かなり無茶があるような．まあthisポインタをconst_castでconstぶっとばして上書きすることまで考えたくらいだしどうってことはないのかもしれないが．というかやってること元々からして無茶を通り越して丸ペケ三角って感じなわけで今更騒いだところでどうしようもない．
＿それにしてもクラスのメンバ関数を__stdcallで定義できたのか．thisポインタは引数と同じように最後にpushされるらしい．右から左に積まれるので，つまりCからみれば第一引数だ．なるほど．
＿まあ特定のアーキテクチャと心中する覚悟ならとかどうとか言うが，実際問題32bit Windows APIを直に叩いている以上32bit Windowsと心中する気満々なわけで．reinterpret_castがどうこうとは言うが，もう端のハナっからWindowsと心中する覚悟なんだから使い方を間違えさえしなければどうってことはない．というかそもそも一部のWindows APIそのものがキャスト前提なのだから仕方あるまい．せいぜいそれ以外のところには型に気をつけたまえということだろう．
＿いや，ちょっと待ってくれ．先に風邪引いたのは私じゃなくて妹君のほうだ．もしうつったのだとしたら私は被害者だっ．
＿などと馬鹿なことを力説して一体どーするというのか．それと悪化傾向な気はするものの今のところ食事はできるのでおかゆってこたないです．
＿あったー！ Get/SetWindowLongではなく，Get/SetWindowLongPtrを使えば良いのだそうな．というわけでせこせこと書き換え．でも肝心のLONG_PTRとかその他が32bit変数でtypedefされてるらしく64bit移植の警告消えないし．まあいいけど．とりあえず説明書きには
この関数は、GetWindowLong 関数の改訂版です。32 ビット版 Windows と 64 ビット版 Windows の両方ともと互換性のあるコードを記述するには、GetWindowLongPtr 関数を使ってください。
なんて書いてあるあたりちゃっかりしてる．まあなんにしろキャストは相変わらずだ．結構好きだけどね．
＿秋はいい．まあ秋になると恒例で体調崩す奴のせりふではないのかもしれないが．
＿常秋の地があったとして，じゃあ私はそこを好きになれるだろうか．常秋の地とは常春の地と違うのだろうか．具体的に春と秋の何が違うっていうのは，例えばどこぞの高気圧がどうこうだとかそういう気象関係から言えるのかもしれないが，そんなごちゃごちゃしたこと言わずとも春と秋の違いはこれで良い．春は夏へ向かうが，秋は冬へ向かう．
＿じゃあ，だったら，常秋の地と常春の地に違いなんか．だってどっちも別の季節へ向かうことは無いのだから．
＿体調を崩したなーと思ってから既に一週間．状況は浮いたり沈んだりと相変わらずか．まあ別にどうってことはないと思うんだが，果て．
＿紫箱からキャンデーが……
＿SendMessage()は思ったより遅い．と思ったが，単にそんな使い方が想定されていないというだけの話だった．大体行って帰ってくるまでに20ms前後のようだから，まあメニューをクリックしてどうこうという程度の用途なら十分なのは間違いない．要するに，そんな用途で使われてるものに数ms単位でのパフォーマンスを期待した私が馬鹿だったということだ．
＿IRCは風邪がうつるらしいから注意しようね．まあ私の喘息はIRCじゃなくたってうつらないと思うけど．多分原因は遺伝だから．
＿これくらい簡単なことだろうと頼んでみたら実はとてつもなく難しかったりあるいは不可能だったり．逆に，これは難しいかなあと控えめに頼んでみたらたった数時間後にはできていたり．とかいうのはよくある話で……
＿boost/preprocessor．すげえ．でもわけわかんねえ．
＿眺めてるといろんなことが出来そうで楽しいのだが，いざ使ってみようと思うとどうやればどうなるのかが分からなくて困る．それにしてもこんなの見てるとC/C++のプリプロセッサってのはえらい強力だったんだな．古くから#defineのマクロでトリッキーかつ便利なことをするってことはやられてきたわけだけど，さすがにこれはどうかと思うような内容．テンプレートでコンパイル時に計算というのもあったし最近はメタプログラミング等と流行のようだが，まさかプリプロセッサとは．このあたり駆使すればEffectiveの一節にあったこの問題は解決だ：ただし、これには１つだけ深刻な欠点がある。プログラムを再コンパイルするときのいつもの長い休憩時間が減ってしまうかもしれない。
＿こうやってしてみるとC#はプリプロセッサが弱ってるのあたり欠点だな．まあ色々理由があって弱ってるんだろうけど．
＿いや，すみません．ここ最近風邪気味で．
＿などと言ってみたところで締め切りは延びまい．体調管理も出来ん奴は半人前だといわれたらそれまでってことだが．まあ不慮の事故で大怪我だとか大病だとかならともかく，風邪程度では．大体ちっと咳しちょるくらいで元気じゃねーかといわれたらはい元気ですって感じだしな．私が悪い．
＿C++って参照の配列は作れないんだね．いや，まあ，参照ってものを考えてみればそりゃそうかって気はするが，これがサポートされるならそれはそれで便利なのに．でも実際サポートしようったってかなり無理な話か．素直にCらしくポインタでまとめればいいんだろうけど，ただの組み込み型だとポインタとサイズが変わんないとか場合によってはポインタよりサイズが小さいってんで実データコピーした方がマシなんじゃないの，とかそういう．まあ結局コピーしちゃったけど．
＿参照の参照が作れないっていうほうはC++のえらい人が標準化団体に欠陥レポートを提出したとかってのがModern C++ Designの脚注に書いてあったような．まあ参照の参照は普通に参照として扱うってのは確かに普通だ．現状禁止されてるのは多分多段参照は混乱を招くからってことなんだろうけど，Modernみたいなことするとこれが仇になるらしいのな．いやまあ，私は理解してないけど．
＿まあ私自身は別に参照の参照が作れなくて困ったっていう体験は無いんだけど．ただ今現実にあるC++の仕様が参照の参照を許していない以上たぶん参照の参照を許すと何か問題があるのだろうと思うわけで，じゃあそれは何なんだろう．足りない脳みそで考えてるうちはせいぜい昨日言ったようにプログラマが混乱するからくらいしか思いつかないわけだが，だったら現状禁止することでの不利益の方が多いのだから標準は変更されてしかるべきだ．まあ，標準の変更ってのはそう簡単じゃなかろうし，実際変更したところで現状が追いつくのはまだ先だろうけど．forの初期化部で宣言した変数のスコープとか．
＿ところで参照の配列が作れたらなあと思ったのはこんなコードを見たときだ．簡単のために変な例になってるとは思うがその辺は許していただきたい．
aEffi = (aEndNum - aStartNum)/(aEndTime - aStartTime); std::cout << "A: " << aEffi << "/msec" << std::endl; bEffi = (bEndNum - bStartNum)/(bEndTime - bStartTime); std::cout << "B: " << bEffi << "/msec" << std::endl; cEffi = (cEndNum - cStartNum)/(cEndTime - cStartTime); std::cout << "C: " << cEffi << "/msec" << std::endl;
＿誰だよこんなコピペコード書いた奴は！ 済みません私です．それはともかく，例ではaとかbとかcとかになってるがこれらは全部意味がある変数名がついている．そしてこれらの名前は変更できないし，連続したメモリ領域にあるわけでもない．こんな条件だ．まあ二行の塊がみっつくらいなら放置するという手も考えるにしろ，実際にはもっと一塊が大きかったのだ．さすがにこんなコピペが続くと後々の変更も面倒だしこうしたいだろう．
int i;
for (i = 0; i < NUM; i++) {
Effi[i] = (EndNum[i] - StartNum[i])/(EndTime[i] - StartTime[i]);
std::cout << Text[i] << Effi[i] << "/msec" << std::endl;
}
＿さて，じゃあ今度EndNumやStartNum等の配列はどうするのか．これらは単に別名なのだから，別名と言えば参照が使える．なるほど，では早速．
const int NUM = 3;
const int &EndNum[] = { aEndNum, bEndNum, cEndNum };
const int &StartNum[] = { aStartNum, bStartNum, cStartNum };
const int &EndTime[] = { aEndTime, bEndTime, cEndTime };
const int &StartTime[] = { aStartTime, bStartTime, cStartTime };
int &Effi[] = { aEffi, bEffi, cEffi };
const char *const Text[] = { "A: ", "B: ", "C: " };
＿てなわけで参照の配列が出てきたわけだが，残念ながらそいつは無理な相談だった．大体，いざコンパイルしようとしたらコンパイラはどうすればいいのだろうか？ こいつらは別に連続した領域にあるわけではない．だからforループを取り外してまたもとの形式に戻さざるを得ない．これは本当にコンパイラの仕事だろうか？ 結局，名前の問題ではなかったわけだ．そもそも設計の段階から連続したメモリ領域に確保し，はじめからforループをまわせるようにするべきだったのである．
＿で，まあ．今にして思えば強力なマクロを使ってという手もあったにはあったのだが，所詮int型だったしコピーのコストが気になる場面ではなかったので，結局以下のような解決となった．
const int NUM = 3;
const int EndNum[] = { aEndNum, bEndNum, cEndNum };
const int StartNum[] = { aStartNum, bStartNum, cStartNum };
const int EndTime[] = { aEndTime, bEndTime, cEndTime };
const int StartTime[] = { aStartTime, bStartTime, cStartTime };
int *Effi[] = { &aEffi, &bEffi, &cEffi };
const char *const Text[] = { "A: ", "B: ", "C: " };
int i;
for (i = 0; i < NUM; i++) {
*Effi[i] = (EndNum[i] - StartNum[i])/(EndTime[i] - StartTime[i]);
std::cout << Text[i] << *Effi[i] << "/msec" << std::endl;
}
＿めでたかったかどうかは謎である．ていうか簡単のためにと思ってforの中身を小さくしたが，これだとむしろ直さない方が幸せに見えるな．
＿ついでに，今にして思ったというプリプロセッサを使う手はこんな具合だ．
#define MACRO(EndNum, StartNum, EndTime, StartTime, Effi, Text) \ Effi = (EndNum - StartNum)/(EndTime - StartTime); \ std::cout << Text << Effi << "/msec" << std::endl; MACRO(aEndNum, aStartNum, aEndTime, aStartTime, aEffi, "A: ") MACRO(bEndNum, bStartNum, bEndTime, bStartTime, bEffi, "B: ") MACRO(cEndNum, cStartNum, cEndTime, cStartTime, cEffi, "C: ") #undef MACRO
＿こっちの方が実行時のコストが発生しなくて良かったかもしれないな．むしろマクロってのはこのために用意されてるのかもしれない気はしてきた．わざわざ参照の配列まで作るような話ではなかったのか．まあ，場合によりけりということにでもしておこう．
＿妖々夢のハイスコアリプレイが登録されてる場所を発見したので落として見てみたが．なんていうか……Phantasmも簡単そうだね！
＿実のところPhantasmが甘くないのは身をもってよく分かっているというか，Extraで猫にたどり着けない実力の持ち主であるからにしてPhantasmなんかプレイした日には数秒でGame Overが目に見えてるのだが．ところが困ったことにハイスコアリプレイともなるとやりこみ具合も実力も違いすぎて，なんとも彼女らは見事にすいすいと弾幕を抜けていくのである．それも，別に際どいところを，というわけではない．かなり余裕を持って抜けていくのだ．当たり判定ぎりぎりのところで避けるような場合は高速自機狙い弾だったから軽く動いた，というようなときくらいである．簡単そうに見えるわけだ．
＿だが実のところ簡単そうに見えるのは本当に簡単なのではなくて，弾幕を巧みに誘導して簡単になるようにもっていっているのが正しいのだろう．Normalのハイスコアリプレイを見て，画面上部で僅かに上下しながらすべての弾を避けていくのを見て，なるほどあれならアイテムを全部集められると納得，だがいざ自分で真似てみればそんなことできんのである．まず画面上部にいけない．いけたところでちょっとしたことでミスするとまた画面下部から再開なため敵の弾の動きが変わる．もう二度と戻れない．簡単ではないのだ．
＿とりあえずリプレイのおかげで無為無策は確実に抜けれることが分かった．安全地帯があったとは．まあ霊夢Aじゃないとタイムアウトを待つしかないけど．というか霊夢Aでもタイムアウトぎりぎりだ．あとリポジトリが切り返せないとぶつぶつ言っていたが，ようやくやり方がわかった．必ず同じ方向に伸びる弾と，自機狙いで伸びる高密度弾の二種類があるのだが，前者は毎回同じ場所を通るので，毎回同じ場所に隙間が出来るのだ．だからこれの左右の隙間の位置を確認，その場所で自機狙いを少しずつ動くことで避け，次の全方位弾が伸びる前に反対側の隙間に待機すればいい．いざやってみると自機狙い弾のうち遅い弾が画面上に残ってやりづらくはあるのだが，割と簡単に取れた．なるほど．
＿いやはや，それは全くもってその通りデス．inlineにすれば実行時のコストも発生しないし，わざわざ見づらい構文のプリプロセッサを使うこともない．
＿が，実際にそれをしなかったのは，ただひとつの関数からしか呼ばれない，つまり全く汎用性のない関数でグローバル空間もしくはメンバ空間を汚したくなかったからというのがひとつ．関数はまとまった機能を用意する単位として使うには便利だけど，変な単位で分割してしまうと関数が増えすぎて混乱しがちなのが嫌な点ではある．関数内関数が定義できればこの問題はなくなるんだが，なんでサポートしないかな．いや，関数内クラスのメンバ関数として擬似的に関数内関数を定義する手法は確かにあるが，あれはあれで構文が汚すぎて好きになれない．
＿それともうひとつ．むしろこっちの方が大きいのだが，その処理単位内でその関数のローカル変数及び引数を大量に使っていたので，関数化しようとすると無駄に引数が増えすぎるのが問題．変化する部分だけを渡したいのに，変化しない部分までわざわざ引数として渡したくなかったのである．構造体にしろというのはもっともだがこんなことのために構造体作りたくないし，構造体作るくらいなら配列でforをまわした方が綺麗だった，という話である．この点，マクロを使うと問題が発生しない．マクロはコンパイル前の段階でソースコードとして展開されるので，その関数内のローカル変数や引数には自由にアクセスできる．だから無駄に引数を増やす必要がないのだ．もっとも，そうやってして勝手にアクセスできるのが問題点でもある．
＿色々関数化の欠点をこじつけてきたが実のところ関数化しなかったのは単にそのとき私が思いつかなかっただけですゴメンナサイ．あと例も悪かったゴメンナサイ．でもいざその部分を見返してみれば後者の部分が結構大きくて，関数化しようと思ったら問題の変化する変数名が4，その関数のローカル変数が3，引数が2とこれだけ渡さなければ関数化できない．しかも後ろの5変数名は全呼び出しにおいて変化しない．他の場所から呼ばれるほどの汎用性もない．となるとちょっと引数が9個は多い気がする．まあCreateFont()は引数14だけどな．そんなときに適用する別のリファクタリングパターンがあるのかもしれないが，その限定された状況だと悪化するような気がしてならないのでやっぱり場合によりけりってことでダメですか？ ダメですか．そうですか．済みません．それと関係ないがCreateFontIndirect()よりCreateFont()の方が好きだ．
＿しっかしなんで関数化することを思いつきもしなかったなかなあ．本気ですっぱり忘れていた．別の場所じゃちゃんと関数化してまとめたのに．うーん．まあ上記の理由で思いついていてもそうしなかった可能性は高いけど……
＿というかこんなことしなきゃならないコードがあるって時点でそもそもその前の部分で間違ってるってのは確かな気はする．
＿こんないい天気にこの気分の悪さはなんじゃいな．特に何もないはずなんだがなあ．まあ目の前に締め切り一個ぶら下がってるけどさ．それとも終わっちまった方の奴だろか．まあしかし終わっちまったもんしゃーないしな……
＿せんせー．だんだん複雑化してます！
＿とはいえなるほど．まあ色々方法はあるもんだね．実のところ私本人が使ったことあるboostっていうとせいぜいcrcとrandomとsoped_arrayくらいだったりして．あ，あとpreprocessor．便利は便利なんだけど実際に使えるようになるにはまだ時間がかかりそう．functionとbindか……いやなんとなくわかりはするんだけど，実際に使ってみないと実感がわかないのがなんとも．機会があったら使ってみようと思うものの，じゃあいつ使えばというのが．適当にどこかで使ってみないとな．
＿あとグローバル空間もしくはメンバ空間を汚すどうこうはC++の規格として汚れるという意味ではなくて，私本人の脳みそが汚れるって意味で．関数が増えると，特に汎用性がなかったりすると何のために作ったんだったか忘れるだとか目的の関数を探すのに時間が掛かったりするとかそういうレベルのお話．関数内関数なら段付けにおけるトップレベルに関数名がこないしというか普通こないように書くし，どうして作ったのかはすぐに分かるから．まあもう少し個人的な話になるとVSのクラスビューのリストがということになるんだけどそれは開発環境異存の話．どうでもいいけどなんかフォルダ分けできなくなってない？ アレ．
＿あとオブジェクト作れってのは困ったことに具体的な手法が思い当たらないんですが私レベル低すぎ？
＿んでなんか色々喋ってるうちに時期を逃しまくった気がするけどもしかして某所の人ってここ見てたりするんだろうか．とりあえずrefFolderは構文上の問題を解決する手段として使えるかもしれないです．特にboost/preprocessorとか使ってると相手が参照だかポインタだかで&つけるだとか*つけるだとかいんや何もつけないだとかということで煩わされたくないので．もしかしたらプリプロセッサに判断させることもできるのかもしれないけど，そこまでプリプロセッサにやらせるのもどうかと思うし．ていうか最近それが目的でポインタのほうのを書いたばっかりだったり．もっとも必要最低限しか書いてない手抜きだけど……
＿ところで移転するのはいいとして結局nonsenseはどこいっちゃったのかしら．