[C/C++] 研究long long * float overflow 可能導致的誤差

最近看bug看到一個奇怪的現象，在64bit的AP執行時，long long * float會有誤差出現，但是32bit的AP卻沒有這樣子的問題出現，直覺上不是應該32bit的AP比較會有問題嗎!?

先來看一下 long long 跟 float ，long long的size是8個byte，float的size是4個byte
long long * float，compiler會將結果存到float的temp變數裡，此時誤差就可能會出現了，但是這個誤差是「有條件」地出現，並不是任何long long的數字乘上float都會產生誤差的

以一個簡單的程式來驗證是否會產生誤差

bool check_longlong(long long v1)
{
    float f = 1.0f;
    long long v2 = long long( v1 * f );
    printf("ori value=%lld, new value=%lld, ori==new=%d", v1, v2, v1==v2);
    return v1==v2;
}

int _tmain(int argc, _TCHAR* argv[])
{
    check_longlong(0xF0000000000);//true - OK
    check_longlong(0x0FFFFFFFFFF);//false - Error!
    check_longlong(0x0FFFFFF);//true - OK
    check_longlong(0x1FFFFFF);//false - Error!
    return 0;
}

[C/C++] 使用STL時，混用Debug & Release Mode的DLL or LIB可能會造成 Crash!

當你的Release mode的EXE，使用Debug mode的DLL，中間如果有操作(new/delete)STL的container，很容易讓AP crash，包括下列的error ...

• Debug Assertion Failed
• _BLOCK_TYPE_IS_VALID
• _CrtIsValidHeapPointer

[Python] 為Python2.5 unittest 加上setUpClass & tearDownClass 的功能

最近使用 Sikuli 替Project作AutoTest的功能，以Python的unittest為架構下去撰寫，發現有些綁手綁腳的地方，因為Sikuli是使用Jython 2.5，連帶的unittest也止於Python 2.5的版本。由於測試的項目眾多，需要撰寫多個TestCase，所以setUpClass與tearDownClass更顯得重要，可以為每個TestCase做pre-process與post-process。偏偏setUpClass與tearDownClass是在Python 2.7後才支援的，所以想在Sikuli裡套用的話，必須自己加一些Code才行了。

[C/C++] 取得LIB目前的DLL module path

如果寫了一個LIB or Cpp檔，讓多個DLL module include使用，該如果拿到目前DLL的module path?

GetModuleFileName() 參數hModule傳NULL的話，只能知道執行檔exe的路徑
要想知道自己在哪個DLL module的話，必須埋一些code才行

EXTERN_C IMAGE_DOS_HEADER __ImageBase
//...
WCHAR dll_path[MAX_PATH] = {0};
GetModuleFileNameW((HINSTANCE)&__ImageBase, dll_path, _MAX_PATH);

Reference :

• StackOverflow - Get Dll path at runtime
• MSDN - GetModuleFileName()