VS2010 & DirectX11 SDK & Windows SDK 編程過程當中的 錯誤/異常/解決方案 記錄 【三】

• 使用 vsnprintf() 獲取 formt 後 整個字符串的長度

 va_list args;

 len = vsnprintf( null, 0, sFormat, args ); 能夠獲取 待合併全部 變參後整個最終 sFormat 的字符串長度， 要求 sFormat 裏的 %?  標記的個數要和 args 的變參個數 一致， 不然會報錯。

 

• 關於 windows 共享內存 CreateFileMapping 、 OpenFileMapping 、 MapViewOfFile 的錯誤使用方式

有數據結構：

struct    SMAO_info
{
    int        m_flag;
    void*    m_data_ref;
};


struct    Node
{
    struct SMAO_info    m_info;
    int                 iData_1;
    int                 iData_2;
    int                 iData_3;
    int                 iData_4;
    int                 iData_5;
    
    ...
    
    BigData                m_bigData;
    
};

在建立 共享文件時， 採用：

HANDLE　　hMapFile = CreateFileMapping( INVALID_HANDLE_VALUE, ... , sizeof(  struct Node ));

並立刻進行相關的內容信息維護：

Node* pNode = ( Node*)MapViewOfFile( hMapFile);
pNode->m_info.m_filag = 1;
pNode->m_info.m_data_ref = pNode->big_data;

問題就出在這裏了， pNode->m_info.m_data_ref 被賦值爲 一個絕對地址， 但通常 createFileMapping 和 openFileMapping 在不一樣的兩個進程中被調用， 共享時 pNode-》m_info。m_data_ref 用 mapViewOfFile() 出來的地址不該該會是相同點， 這種方式實現的共享時不安全的， 將其修改成 

struct    SMAO_info
{
    int        m_flag;
    size_t  m_data_ref_offset;
};

及相對於被映射的 共享數據頭 的偏移值， 即便不一樣進程映射出來的起始地址不一樣， 但仍能經過偏移量 計算獲取到 有效的 地址。

 

• ACE 沒法解析的符號

ACE_TEST1.obj : error LNK2019: 沒法解析的外部符號 "int __cdecl ace_main_i(int,char * * const)" (?ace_main_i@@YAHHQAPAD@Z) ，該符號在函數 "private: virtual int __thiscall ACE_Main::run_i(int,char * * const)" (?run_i@ACE_Main@@EAEHHQAPAD@Z) 中被引用

將 主函數 改成 int main( int argc, char** argv), 具體緣由請參考：http://blog.csdn.net/lwhans/article/details/3980651