先日の日記にて静的ライブラリの作り方がググ〜っても仕方ない♪である旨をさりげなく書いてたのですが，その原因が分かった気がします．VC だと「スタティックライブラリ」なんですね．「静的ライブラリ」で検索してばっかりだったからろくにヒットしなかったようです．実際にさっきスタティックの方で検索してみたら MSDN の記事（作り方と使い方のチュートリアル）にもろヒットしましたｗ そこに trino さんの指摘にもあったことですが，空のプロジェクトからではなく最初からスタティックライブラリを作らせる方法も書いてありましたｗ
オブジェクト指向の三大要素として挙げられる「カプセル化，継承，多態性」の中の「カプセル化」を Java で分かりやすく解説しようと思います．＞＜
まずカプセル化というのは，データとそのデータの処理を一箇所で管理するということです．そこでクラスという概念が出来ました．
class Excalibur {
}
class YaoiHole {
}
class Seme {
Excalibur excalibur;
public Excalibur getExcalibur() {
return excalibur;
}
}
class Uke {
YaoiHole yaoiHole;
public void insert(Excalibur excalibur) {
//アッー！
}
}
＜使用例＞
Seme seme;
Uke uke;
uke.insert(seme.getExcalibur()); //アッー！
うん，もうここまで書いて飽きた (´・ω・｀) 普段ならこんなネタ即座にボツですが，せっかくの腐な祭なのでアップします．継承も多態性もネタはあるんだけど，気力がないのでまた気が向いたら書きます．
楽にポイントを稼ぐ方法を考えてみました．
魔方陣の難しいを選ぶ → 問題を撮影して DS を閉じる → 手計算で答えを求める → 神速で答える → ウッウーウマウマ
難易度「難しい」だと得点が「294000 / 平均回答時間」という式で出されます（らき☆すた萌えドリル wiki より）．ちなみに正解率100%は当然満たすべき条件とします．これで仮に平均回答時間が 2 秒になったとしても，1 回で 1470 ポイントも入手出来ることになります．1 分程度かけて600 〜 700ポイント稼げるツンデレ判断よりもかなり高効率だと思います．（追記）実際問題として平均回答時間 2 秒というのは不可能でしたｗ 本当に神速でやって 4 秒が精一杯だと思います（※ちなみにこの速度でやると高確率でミスる）．
しかし，手計算の部分を自動化しないことにはツンデレ判断の方が早いかも知れません．というのも，難易度「難しい」は仮埋めをしなければ出来ない問題が出てくるからです．
というわけで，プログラマとしての力を発揮するときです．魔方陣を解くプログラムを組みましょう＾＾ 現在少女コーディング中... 組めたらアップしようと思います．
ちなみに，ググっても真らき☆すた萌えドリル特化の魔方陣（4 * 4 で 和が 34 で空欄候補がランダム）を解くプログラムなんてそうそうありません．学術的過ぎるものや汎用性が高過ぎて使うの面倒臭そうなのばっかりです．
（追記）そして，結局魔方陣を解くプログラムは上記の理由と面倒臭さのために凍結しました ＼(^o^)／
最近 dqmaniac さんが東方永夜抄をやっている旨をよく日記に書いてて，それを読んで自分もまたやりたくなったのでやってみました．最近東方…というか STG をほとんど真面目にプレイしてなかったのでさすがに Extra 一発取りは難しいかなぁ…と思いつつ詠唱組でやってみたら一発余裕でした．スコア13億出してどうやら詠唱組ハイスコアも出したようです（どんだけ低かったんだと）．
やはり3年前にアホみたいにやり込んで鍛えた永夜抄の能力はそう簡単には無くならないようです．
無くなったのはやる気だけですね (ノ∀`)
STL の vector で，
for (unsigned int i = 0; i < vec.size(); ++i) { /* ループ処理 */ }
というような書き方を BCC ではしょっちゅう使っていましたが，これが VC だと警告を出されます．size メソッドの戻り値である size_t 型が 64 ビット対応していることが原因のようです．
では素直にイテレータを使えば解決か？というとそう簡単でもありません．例えば
for (unsigned int i = 0; i < vec.size(); ++i) {
vec.at(i) = vec2.at(i);
}
のように別の vector の要素と対応を取りながら処理をするような部分が非常に書き辛くなります．こりゃやってられん ／(^o^)＼ 貴様のために，わしは宇宙塩を味噌ブリだぞ．許せる！って感じです．
てことで，オプションの「64 ビット移植への対応」を「いいえ」にしましょうｗ そもそも作ってるのが Win32 アプリケーションなので 64 ビット？シリマセーン ＼^o^／ てことで解決なのです (^o^) だいたい 64 ビット対応なら int 型も 64 ビットになって然るべきだと思うのですがねぇ… なんで size_t 型だけ… この辺はコンパイラを作る人にならないと分からない事情があるのかしら？
ここ数日ずっと VC のコンパイラの厳しさにヒーヒー言ってる気がします．警告の出方が BCC の比じゃなくてほんと大変ですわ．
（2008-04-11 追記） この内容には誤りがありました ＼(^o^)／ そもそも添え字に unsigned int を使うのがダメっぽいです．添え字には size_t を使うみたいです．修正した内容の記事はコチラ．
自分はこの関数が大好きなのですが，バッファオーバーフローがどうのこうのという理由で最近はあまり使われないのでしょうか？ VC でも sprintf_s や sscanf_s という独自の安全な関数が用意されていて，そちらの利用を推奨してきます．ちなみに sprintf はサイズチェックを行わないので snprintf を使うといいと学校でプログラムやってるときにどっかで聞いたような気がするのですが，どうやら snprintf は C の標準ではなく VC には入ってません．それ以外にも snprintf はチェックはするがエラー防止には本質的に関わらないとかいう記述も見つけてしまってさぁ大変，と言った感じ．
この 2 つの関数と同等かそれ以上の働きを行い，使い勝手がこれに劣らず，標準になっている関数って C/C++ にありましたっけ？ C++ だけじゃなくて C でも出来るならなお良いです．
今ニコニコ動画で個人的に凄く注目してる作品がありまして，それがこれらの動画です．
(sm2283732) こなたとかがみのファイナルファンタジー4(仮)・第一話「旅立ち」
(sm2341413) えふ☆すた(仮)・第二話「霧の谷の少女」
(sm2484404) FF4のシナリオをらき☆すたでリメイクしてみた(仮)・第三話「水底の主」
暗黒騎士のこなたや竜騎士かがみのイラストに，絶妙に共感出来るアレンジストーリーが実に良い味出してると思うのですが，どうでしょう？うｐ主には頑張って最後まで作り上げて欲しいです．
ライブラリ作成時のコンパイルもプロジェクト作成時のコンパイルも，コンパイルに関しては完全無警告で全て終わるのです．が，その後リンクするときに膨大なエラーが出ます (^ω^)
error LNK 2005: std::unk_unk は既に unk.lib (とか unk.dll) で定義されてます ←こんなんが80個くらい
そんな関数作った覚えねぇーっつーの (^ω^)
Visual C++ 2005 爆発しろです．もうほんと．何が悪いんじゃろ？ちなみに LNK 2005 でググって MSDN とか読んでも何書いてるのかほとんど分かりません．あんなので分かるのは予め分かってる人だけだろ．分からん人が読んで分かるような表現しろってんだ．
先日魔方陣でポイントが稼げるという机上の空論を持ち上げたばっかりなんですが，明らかに最もポイントが稼げるのは巫女祭壇でした．何回も成功させたら参拝者を15,000人くらいにすることが出来て，お布施うめぇｗｗｗｗということで簡単にポイントカンスト（99999ポイント）しました．先日の日記に惑わされた人がもし居れば（普通に考えていないだろうけど），ごめんなさい，素直に巫女祭壇を成功させて下さい (^ω^)
今回はサークル参加は見送ることにしました．どう考えても間に合いそうにないのと，あと学校とか進学とかの関連でサークル活動よりも優先順位の桁違いに高いことがいくつかありますので．
(sm2652345) 自作の妄想FFをニコ厨という名の友人に視聴させる(仮)・第四話「黒幕」
新作ｋｔｋｒ！ (＞ワ＜) なんかこのシリーズのタグに「こなたんファンタジー」というのがあるようなので，うちでもそれを仮として使います．
ここで早くもひよりんが登場します．ジョブ「どうじんさっか」には吹いたｗ 初期のこなた同様いい感じにヘタレてくれてます．さすがインドア人間．
あとあやのの扱いが酷い，黒い…というより別キャラ（朝倉涼子）になってるので純粋なあやのファンは要注意っす．
先日スタティックライブラリの作り方を紹介した記事（こちら）を書きましたが，どうもこの方法ではリンク時にエラーが発生することがあります．そのエラーに関しても以前少々書いたのですが，主なものとしては LNK2005 というエラーです．
で，厳密に原因を究明したわけではないのですが，これは「ライブラリは Debug も Release も考える必要ないじゃん」理論がマズいみたいなのです．というのも，「プロジェクトのプロパティ（Alt + F7 で開けるあれ） > 構成プロパティ > C/C++ > コード生成 > ランタイムライブラリ」の値が，ライブラリ側と使おうとしているプロジェクト側で一致していないと駄目みたいだからです．ここの値，Debug バージョンなら マルチスレッド デバッグ DLL (/MDd) に，Release バージョンなら マルチスレッド DLL (/MD) になるのです．
で，自分でライブラリとプロジェクトのコード生成の値を不一致させるという実験をしてみました．が，同様のエラーを出すことは出来ませんでした．
warning LNK4098: defaultlib 'MSVCRTD' は他のライブラリの使用と競合しています。/NODEFAULTLIB:library を使用してください。
という警告止まりでした．
ちなみにあとよく分からないのが，ライブラリファイル（.lib ファイル）のサイズが妙に大きくなるというのは Release バージョンだけだったということです．Debug バージョンでは程よく小さくなってました．なんで？デバッグ用のコードとか情報が埋め込まれてることを考えると逆のような気がするんですけど(^^;
まぁ，マズそうなのはそこだけでした．ライブラリをリンクさせる方法やインクルードパスを通す方法なんかは以前書いた記事の通りで大丈夫でした．てことで，これから玉子焼きうめえｗｗｗｗのためのライブラリ移植＆プロジェクト作成作業を再開しようと思います．また別のエラーが出たら，そのときはそのときっすよｗ
ライブラリを作るときの「コード生成 > ランタイムライブラリ」の値を Debug で「マルチスレッドデバッグ DLL (MDd)」に，Release で「マルチスレッド DLL (MD)」にしましたが，やはり大量のリンクエラー（ともちろん警告も）が出て涙目でした．
ここで改めて DX ライブラリでプロジェクトを作る方法を読み返してみました．すると，プロジェクト側のランタイムライブラリの値は Debug で「マルチスレッドデバッグ (MTd)」，Release で「マルチスレッド (MT)」にするらしいじゃないですか．てことで，早速ライブラリ側を変更．リビルドして，再びプロジェクトとリンク．
結果，やはり大量のリンクエラー（ともちろん警告も）が出て俺 ＼(^o^)／ オワタでした．
そして新しく出たエラーや警告をググル先生に尋ねてみたところ，どうも次に考えられるのは，extern "C" の関連じゃないかという可能性が出てきました．やばいですね，この機能は実は僕は使ったことがないのです．しかし，自分は今まで C++ のコードしか書いてないはず．それがどこかで勝手に C としてコンパイルされてる…？ …という感じに，また泥沼です．
というか，もう一旦既存のプロジェクトは捨てて，新規プロジェクトとして 0 から作り直そうかとも思い始めてます．どうする小僧！？
らちが明かないので 0 からプロジェクトを作り始めました．何を作るかが大事だって気付いたばっかりなのに，またこの男は性懲りもなくどう作るかにばかり拘っていたんですね．Visual C++ の使い方を覚えないといかん，と思ったのは悪くないけど，そっちに拘り過ぎてました．さっさと諦めてりゃ今頃どう考えてもとりあえず動くものなら作れてただろうに… 救いようがないです．
と落ち込んでばかりもいられないので，暇な時間を見つけてはどんどん作り上げていこうと思います．まきまき 7 のある日にでもまた何か配布出来たらいいなぁ．
とりあえず画面中央に白い点を一つだけ描画するプログラム，という程度にまでレベルを落として，それからリンク時のエラーを起こさぬようコツコツ作っていたのですが，とうとうかつて作ったライブラリ内にあった仕組みが必要な段階にまでやって来ました．もちろん，ライブラリをリンクさせるとリンクエラーが出ます．そこで，別途作ったライブラリのリンク時にエラーが出るのなら，ライブラリのソースそのものをプロジェクトに組み込んでみようか，と思いソースとヘッダーをプロジェクト内に引っ張り込んで来ました．ライブラリとは言えまだまだせいぜい十数個のファイルなので，手作業でも十分にファイルのコピペは出来ました．
で，リンクしてみると，エラー．
libcpmtd.lib(xdebug.obj) : error LNK2019: 未解決の外部シンボル __malloc_dbg が関数 "void * __cdecl operator new(unsigned int,struct std::_DebugHeapTag_t const &,char *,int)" (??2@YAPAXIABU_DebugHeapTag_t@std@@PADH@Z) で参照されました。
この前の大量に出てきたエラーの中に LNK2019 もあったような気がします（メモってない orz）．しかし，ここでようやく確信しました．ライブラリそのものの方に問題があるのだと．
ということで，コメントアウトを徹底的に繰り返し，とにかくエラーが出なくなるまで粘る．そして，怪しそうな箇所からコメントアウトを解禁していって…という実に初歩的な方法をとってとうとう原因を突き止めました．
それはなんと「あるライブラリのヘッダファイルに書かれた #include <fstream>」でした．この include 文と，ifstream やら ofstream やらを使っている部分をコメントアウトする（※こちらは fstream がそもそもないのでコンパイルエラーが起こるため）だけで，リンクエラーは完全に消えました．
ほんとに訳分かりません ／(^o^)＼
でもヘッダファイルに #include <fstream> が書けないと色々と便利な自作ライブラリが使えなくなるので困ります．というか多分ゲーム作れませんｗ
まぁ今日のところは原因が分かっただけでも良しとしますかね．
研究室が決まってこの前部屋の掃除を済ませて，本日ようやく PC が割り当てられました．で，Windows XP のインストールやら SP2 の適用やら Cygwin のインストールやらを丸一日掛けてやりました．
でもまだ終わってません．というか各種ドライバと Cygwin のインストールが手間取りすぎました．特に Cygwin の方．あんなの Windows のインストーラじゃないやい！爆発しろ！
残ってるのは LaTeX と Ghostscript と J2SDK と Eclipse とウィルスバスター．…面倒臭すぎる orz
実体は http://tamaran.sakura.ne.jp/ka/ なんですよね．でも，さくらインターネットの独自ドメインサービスで http://kaosf.kirara.st/ っていうのでも同じ所にアクセス出来るようにしてあるんです．なんでこんなことしてるかって，そしたら tamaran から独立した存在になれるじゃないですか．そして，さくらインターネットでなら後で別のスペースを借りても同じ URL でアクセス出来るように出来るじゃないですか．
しかし，困ったことに…いや，それほど困らないとも言えますが，「かおすふぃーるど」でググって出てくるのは tamaran.sakura.ne.jp/ka/ の方なんですよね．kaosf.kirara.st/ の方が出てこないんですよ．もう自分としては kaosf.kirara.st/ の方が本物で， tamaran.sakura.ne.jp/ka/ でもアクセス出来ますよ，って解釈にしたいんですが，ググル先生はそれをお許しにならないようで orz
まぁ別に移転の予定も必要もないので，実質何も困りはしないのですが (´∀｀)
でも，もし kaosf.kirara.st/ の方で皆がブックマークなりリンクなりしてくれてたら，仮に移転するときに「リンクやブックマークの変更をお願いします」ってわざわざ言わなくても良いんですよね．勿体無いなぁ．