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