2010-01-02 (土)
自分で使っている文字コード変換のためのencode.hを公開しておく．
EUC-JPとかWin32APIを使う場合は変換できないかも．
謎のイテレータがたくさん入っていますが，正常な文字列以外を渡したりするとおかしなことになるので，使い物になりません．イテレータじゃなくてストリームとして再実装する予定です(やりたくなったら)．
*C++のvtableが憎い
ポインタを介さないアクセスの場合は，仮想関数テーブルを見る必要が無いので，メソッド呼び出し時のオーバーヘッドはありません．
が，インスタンス生成時は別で，オブジェクトの先頭にvtableを埋め込む処理が入ります．
これが厄介で，ごく単純な処理の場合は賢いコンパイラはvtable自体の存在を忘れてくれますが，配列だったりすると全ての要素にvtableを埋め込んでくれます．
Nanika o[16];
とかすると，Nanikaは初期化不要でコンストラクタも無いのに16回のループが発生してしまいます．ポインタ経由でアクセスする可能性があるなら仕方ない処理なのですが，その場所ではその仮想関数テーブルは使われないのです．
遅いと困る箇所だったので，テンプレートで実装したのに，クラスの宣言自体にvirtualがあると，無駄な処理が発生してしまいます．
とりあえず，Nanikaのvirtualが無い版を作って無理やり解決したけど，どうにかならないのかなあ．今回の場合は，データと処理を別クラスにする方が結果として綺麗になりそうだけど，後から変えるのは面倒．
もう少し，仮想関数とテンプレートを簡単に併用できるようにして欲しいな．
*もしもコンピュータを再設計して良いなら
とりあえず，記憶領域の最小単位を10ビットとかにしたい．
現在は8ビットが最小単位で管理されていて，その倍数の32ビットや64ビット単位でCPUも計算を行っています．これらは，2のn乗ビットになり，CPUの回路やアルゴリズムの実装が綺麗になるという利点がありますが，今となっては弊害の方が多い気がします．
8ビットCPU時代ならともかく，128ビットのレジスタが普通に存在できるCPUにおいて，8ビットを10ビットにしたところで，効率は下がらない気がします．それよりも，現実社会の事象を扱うソフトを書くときは，10ビット単位の方が効率よく計算や格納ができそうです．
8ビットだと足りないけど，10ビットなら足りるという問題は結構あります．マイコンを使ってて，よく使うA/D変換器なども10ビットです．でも，マイコンのレジスタは8ビットだったりするので2ビット捨ててしまうか，6ビットと計算時間を犠牲にしてそのまま格納するかでかなり迷います．256段階のデータは少し荒すぎるので10ビット欲しいのは確かなのですが，何かが犠牲になってしまいます．
タッチパネルに触れる時や，デジタル温度計を見かけたときに，自分だったら作るとき何を思うかが一瞬だけ脳裏をよぎります．
Unicodeを策定するときも，文字数を少なくするために中国や日本の漢字の似たものを統合するというような乱暴なことをしなくて済んだと思います．この問題のしわ寄せは，現在も問題が出ていますし，かなり先の将来まで引きずると思います．
あと，これから迎える2038年問題も考える必要は無かったかも．
とにかく，８ビットという単位のせいで発生している損害はかなり大きいと思う．