va_list args;windows
len = vsnprintf( null, 0, sFormat, args ); 能够获取 待合并全部 变参后整个最终 sFormat 的字符串长度, 要求 sFormat 里的 %? 标记的个数要和 args 的变参个数 一致, 不然会报错。安全
有数据结构:数据结构
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; };
在建立 共享文件时, 采用:app
HANDLE hMapFile = CreateFileMapping( INVALID_HANDLE_VALUE, ... , sizeof( struct Node ));函数
并立刻进行相关的内容信息维护:this
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() 出来的地址不该该会是相同点, 这种方式实现的共享时不安全的, 将其修改成 spa
struct SMAO_info { int m_flag; size_t m_data_ref_offset; };
及相对于被映射的 共享数据头 的偏移值, 即便不一样进程映射出来的起始地址不一样, 但仍能经过偏移量 计算获取到 有效的 地址。.net
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) 中被引用code
将 主函数 改成 int main( int argc, char** argv), 具体缘由请参考:http://blog.csdn.net/lwhans/article/details/3980651orm