-
使用 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