C++の単純な機能のベンチマークを取るのがちょっと楽しくなってきてる私ですが、なんだかよくわからなくなってきました。

単純なループで測定した場合と、自作のタスクシステムに組み込んだ時に測定した場合で、全然速度が違うんですよ。差が開いたり狭まったり。
やっぱ最適化で色々省略されてたせいかなぁ。

ちぅわけで、自作タスクシステムに組み込んだ場合の数値を載せとく。

続きを読む →

ちょっと気になったので、演算子オーバーロードを実装したクラスでの演算と、普通の変数での演算速度にどれくらい違いがあるのか計ってみた。

予想では、演算子オーバーロードしたほうは、少なくとも関数呼び出しのオーバーヘッドで遅くなるだろうと思うけど・・・
続きを読む →

にわかに技術系blogっぽくなってきてる当blogですが。

DirectXとかSeleneとか、要求する文字コードがunicodeつーかwchar_tだったりする事が多々あるんだけど、同時に使ってる別のライブラリがSJISとかMultiByteつーかcharだったりして、でも実際には半角文字しか使わないってことが良くある。

で、char→wchar_tの変換は普通MultiByteToWideChar使うんだけど、半角しか使わないのにMultiByteToWideChar使うのはなんか無駄なんじゃね？
ってことで、試しに作ってみたら速かったので公開。

続きを読む →

必ず数字が引数に渡されるという限定した状況に限り使用可能な、atoiとatof（数字文字列を数値に変換するＣ言語関数）を作ってみました。
作ってみたっていうか、こちらの丸パクリして、ほんのちょっとさらに高速にしてみただけですけど。

続きを読む →

もしかしたらWindows環境だけのことで、他のOSでは問題ないのかもしれないけど（いや、そんなことはないと思うけど）

C++でファイル読込みするときに、fstreamだけを使ってファイルサイズを得る方法をググると、

//ファイルを開く
ifstream ifs("test.dat", std::ios_base::binary);

//ファイルサイズ取得？
streamsize size = ifs.rdbuf()->in_avail();

なんて感じのコードが結構でてくるんだけど、ちょっと待って欲しい。

in_avail()の戻り値はMSDNによると

バッファから読み取ることが準備完了している要素の数です。

ということで、ストリームバッファ内で現在利用可能なバイト数なんですよ。

なので、小さなファイルならいいけど、ストリームバッファのサイズを超えるファイルのサイズを得ようと思っても、バッファの上限までしか得られない。
環境によって違うかもしれないけど、さっき試したら4096以上は返ってこなかった。

じゃぁどうしたらいいかというと、

//ファイルを開く
ifstream ifs("test.dat", std::ios_base::binary);

//ファイルの最後の位置（＝ファイルサイズ）を得る
size_t fileSize = (size_t)ifs.seekg(0, std::ios::end).tellg();

//ファイル読み取り位置を先頭に戻す
ifs.seekg(0, std::ios::beg);

コレで正確なファイルサイズが取れる。

速度はもしかしたらin_avail()の方が早いかもしれないから、扱うファイルのサイズが小さいことが解ってるならin_avail()を使った方が良いのかもしれないね。