別件が忙しくなってきた影響で時間が余り作れなくなってきています。
その割にはこんな記事を書いているのが微妙といえば微妙ですが・・・。
一応アクセスログについては確認しているのでその中で気になったことを書いてみたいと思います。
Win64ではthiscallの扱いはどうなるのか？
この記事の続きのような物です。
Win64での呼び出しは_cdecl=_stdcall(=_fastcall)であることは記事中にもあることですが、では_thiscallの扱いはどうなるのか？を調べてみました。
対象はやはりVisualStudio2005でアセンブラコードを含めてビルドさせて確認しました。
で、どうなったかというと
rcxレジスタにthisポインタ、整数第一引数がrdxレジスタ、以下・・・
となりました。つまり、呼び出し方を無理にコードで書くなら
class foo{
int bar(int x,int y)
{
・・・
}
};
をWin64のコンパイル時に
class foo{
static int bar(foo * const this,int x,int y)
{
・・・
}
};
のように変換している、ということらしいです。
ちなみに、Win32上で無理にクラス呼び出しに対して_cdeclや_stdcallをつけるとその通り(第一引数をthisポインタにするよう)に呼び出し形式が変わります。
この辺を気にするのはプログラム解析を行うような人くらいだと思いますが。最適化とか関係ないですし。
やはりコードサイズが減った理由は不明だが
別件で作っているプログラムのサイズも100kB分下がっていたのでYUV=>RGB変換ルーチンを書き直していた段階で何かの最適化がかかるようになってルーチンが外されたのでは？と推測しています。
それはいいのですが、DirectShow Extend Filter Libraryには一応サンプルコードがついていますので、使用方法はそちらを参考にしてください。
C++&DirectShowで動画の再生をやろうとした人なら理解できるコードのはずなのですが・・・。krmovieとペアにして使う場合はさらに簡単のはずです。
確かにLoadLibrary経由での使い方は示していませんが、関数定義はちゃんと付属のテキストにありますのでそれを定義してGetProcAddressで取得すればほぼ同じ使い方になりますので。
結局電池が急激に減る減少のリセットは再起動しかないのかな？
これもよくわからないことの一つです。ちなみにXperia acroのこの時点で最新の状態であっても再起動でなぜかアプリ一つ分だけ変な場所に移動するようです。
どちらの件についてもどうしてこうなっているのかわからないので愚痴っぽく書いているだけです。
一日で電池を使い切るような使い方をしている人にはあまり意味のない現象のような気もしますが。