全局钩子中使用postmessage

我只是想解释一下为什么需要使用一个共享的数据段，如下：

#pragma data_seg("mydata")              //编译器识别的指令用以在虚拟内存中开辟一个数据段存放该指令下面的数据
HINSTANCE glhInstance=NULL;             //DLL实例（或者说模块）的句柄。
HHOOK glhHook=NULL;                     //鼠标钩子的句柄。
HWND  GlobalWndHandle[100]={NULL,.....};//用来存放被隐藏的窗口的句柄，以数组的形式保存。
//该数组必须初始化，原因见下文。我以“......”省略。
#pragma data_seg()                      //与#pragma data_seg("mydata") 首尾呼应表示该数据段的结束。

加入上述数据段以后还应在项目里插入一个“*def”文件,用："SECTIONS mydata READ WRITE SHARED"将mydata数据段设置为一个可读写的共享段。在程序里加入预编译指令，或在开发环境的项目设置里也可以达到设置数据段属性的目的，我就不一一赘述了。
我前面讲过，系统通过调用放在DLL中的钩子回调函数来实现全局钩（钩取所有窗口的鼠标消息），操作系统对DLL的操作仅仅是把DLL映射到需要它的进程的虚拟地址空间里去。也就是说，DLL函数中的代码所创建的任何对象（包括变量）都归调用它的线程或进程所有。“DLL在WIN32中什么都不拥有”——这句话很重要。比如我们在DLL里建立了一个变量a，而我们的这个DLL文件又被两个进程所调用，这两个进程的中都用到了a可这绝对是两个不同存储单元中存储的两个a，它们之间没有丝毫的联系。给其中一个赋值也绝对不会影响到另一个。而对于本程序的一些数据是需要在不同的进程中保持唯一的（也可以说是一致），比方说： HWND GlobalWndHandle[100]它是用来保存程序做了隐藏的窗口之句柄的数组。当程序运行，我在任意窗口A中同时按下了鼠标左、右键，由于设置了鼠标钩子，系统会调用DLL中的钩子处理函数截获消息并加以处理，即把目前的可见窗口隐藏并把窗口句柄保存到GlobalWndHandle[100]数组中以备将来显示之用。如果不把GlobalWndHandle[100]放到一个共享的数据段里，系统就会在目前我们截获鼠标消息的A窗口的进程的地址空间里开辟HWND GlobalWndHandle[100]来存储窗口句柄。这样对于其他进程就不能方便地得到这个进程存入GlobalWndHandle[100]数组的数据了。这时只能将GlobalWndHandle[100]等需要跨进程访问的变量数据放在一个共享的数据段里了。另外，需要特别注意——必须给这些变量赋初值（就象我在程序代码里傻呼呼地写了100个NULL一样。你可以不初始化这个数组试验一下，有助于你理解我上面的话），否则编译器会把没有赋初始值的变量放在一个叫未被初始化的数据段中。

简单的说(在制作老板键的时候)由于dll什么都没有,dll中的全局变量实际上是在窗口中,所以在隐藏窗口后,你原先存储在dll中的hwnd随窗口而隐藏,你无法选中窗口,也无法取得此Hwnd。所以无法恢复窗口，解决办法就是开一段共享空间。从而可以在任何时候获取到Hwnd。

posted @ 2008-06-02 09:31 小C 阅读(918) | 评论 (0) | 编辑 收藏

C++开源跨平台类库集

posted @ 2008-05-22 10:33 小C 阅读(313) | 评论 (0) | 编辑 收藏

VC lib链接错误的总结

通过dumpbin /DIRECTIVES my.lib查看lib的缺省标准库版本
然后调整自己的缺省标准库版本来适应第3方库

若要使用此运行时库	请忽略这些库
单线程 (libc.lib)	libcmt.lib、msvcrt.lib、libcd.lib、libcmtd.lib、msvcrtd.lib
多线程 (libcmt.lib)	libc.lib、msvcrt.lib、libcd.lib、libcmtd.lib、msvcrtd.lib
使用 DLL 的多线程 (msvcrt.lib)	libc.lib、libcmt.lib、libcd.lib、libcmtd.lib、msvcrtd.lib
调试单线程 (libcd.lib)	libc.lib、libcmt.lib、msvcrt.lib、libcmtd.lib、msvcrtd.lib
调试多线程 (libcmtd.lib)	libc.lib、libcmt.lib、msvcrt.lib、libcd.lib、msvcrtd.lib
使用 DLL 的调试多线程 (msvcrtd.lib)	libc.lib、libcmt.lib、msvcrt.lib、libcd.lib、libcmtd.lib

libcmt.lib--MT--静态库使用MFC，msvcrt.lib--MD--共享DLL使用MFC

ps：不确定猜想,用#pragma comment(lib,"*.lib")包含的库并不是全部编译进入程序,而在项目中包含的(添加->现有项)lib是全部编译进入程序的。所以某些时候即时第3方库的默认库和项目不同，可以通过仅仅使用#pragma comment的方式来使用lib,而不将其添加入项目，从而不需要改变项目的运行时库。

原文： http://billwan.spaces.msn.com

    许多Visual C++的使用者都碰到过LNK2005:symbol already defined和LNK1169:one or more multiply defined symbols found这样的链接错误，而且通常是在使用第三方库时遇到的。对于这个问题，有的朋友可能不知其然，而有的朋友可能知其然却不知其所以然，那么本文就试图为大家彻底解开关于它的种种疑惑。

    大家都知道，从C/C++源程序到可执行文件要经历两个阶段:(1)编译器将源文件编译成汇编代码，然后由汇编器(assembler)翻译成机器指令 (再加上其它相关信息)后输出到一个个目标文件(object file,VC的编译器编译出的目标文件默认的后缀名是.obj)中；(2)链接器(linker)将一个个的目标文件(或许还会有若干程序库)链接在一起生成一个完整的可执行文件。

    编译器编译源文件时会把源文件的全局符号(global symbol)分成强(strong)和弱(weak)两类传给汇编器，而随后汇编器则将强弱信息编码并保存在目标文件的符号表中。那么何谓强弱呢？编译器认为函数与初始化了的全局变量都是强符号，而未初始化的全局变量则成了弱符号。比如有这么个源文件:

extern int errorno;
int buf[2] = {1,2};
int *p;

int main()
{
?? return 0;
}

其中main、buf是强符号，p是弱符号，而errorno则非强非弱，因为它只是个外部变量的使用声明。

    有了强弱符号的概念，链接器(Unix平台)就会按如下规则(参考[1]，p549~p550)处理与选择被多次定义的全局符号:

规则1: 不允许强符号被多次定义(即不同的目标文件中不能有同名的强符号)；

规则2: 如果一个符号在某个目标文件中是强符号，在其它文件中都是弱符号，那么选择强符号；

规则3: 如果一个符号在所有目标文件中都是弱符号，那么选择其中任意一个；

    虽然上述3条针对的是Unix平台的链接器，但据作者试验，至少VC6.0的linker也遵守这些规则。由此可知多个目标文件不能重复定义同名的函数与初始化了的全局变量，否则必然导致LNK2005和LNK1169两种链接错误。可是，有的时候我们并没有在自己的程序中发现这样的重定义现象，却也遇到了此种链接错误，这又是何解？嗯，问题稍微有点儿复杂，容我慢慢道来。

 众所周知，ANSI C/C++ 定义了相当多的标准函数，而它们又分布在许多不同的目标文件中，如果直接以目标文件的形式提供给程序员使用的话，就需要他们确切地知道哪个函数存在于哪个目标文件中，并且在链接时显式地指定目标文件名才能成功地生成可执行文件，显然这是一个巨大的负担。所以C语言提供了一种将多个目标文件打包成一个文件的机制，这就是静态程序库(static library)。开发者在链接时只需指定程序库的文件名，链接器就会自动到程序库中寻找那些应用程序确实用到的目标模块，并把(且只把)它们从库中拷贝出来参与构建可执行文件。几乎所有的C/C++开发系统都会把标准函数打包成标准库提供给开发者使用(有不这么做的吗？)。

 程序库为开发者带来了方便，但同时也是某些混乱的根源。我们来看看链接器(Unix平台)是如何解析(resolve)对程序库的引用的(参考[1]，p556)。

 在符号解析(symbol resolution)阶段，链接器按照所有目标文件和库文件出现在命令行中的顺序从左至右依次扫描它们，在此期间它要维护若干个集合:(1)集合E是将被合并到一起组成可执行文件的所有目标文件集合；(2)集合D是所有之前已被加入E的目标文件定义的符号集合；(3)集合U是未解析符号 (unresolved symbols，即那些被E中目标文件引用过但在D中还不存在的符号)的集合。一开始，E、D、U都是空的。

(1): 对命令行中的每一个输入文件f，链接器确定它是目标文件还是库文件，如果它是目标文件，就把f加入到E，并把f中未解析的符号和已定义的符号分别加入到U、D集合中，然后处理下一个输入文件。

(2): 如果f是一个库文件，链接器会尝试把U中的所有未解析符号与f中各目标模块定义的符号进行匹配。如果某个目标模块m定义了一个U中的未解析符号，那么就把 m加入到E中，并把m中未解析的符号和已定义的符号分别加入到U、D集合中。不断地对f中的所有目标模块重复这个过程直至到达一个不动点(fixed point)，此时U和D不再变化。而那些未加入到E中的f里的目标模块就被简单地丢弃，链接器继续处理下一输入文件。

(3): 当扫描完所有输入文件时如果U非空或者有同名的符号被多次加入D，链接器报告错误信息并退出。否则，它把E中的所有目标文件合并在一起生成可执行文件。

 
 上述规则针对的是Unix平台链接器，而VC(至少VC6.0)linker则有相当的不同: 它首先依次处理命令行中出现的所有目标文件，然后依照顺序不停地扫描所有的库文件，直至U为空或者某遍(从头到尾依次把所有的库文件扫描完称为一遍)扫描过程中U、D无任何变化时结束扫描，此刻再根据U是否为空以及是否有同名符号重复加入D来决定是出错退出还是生成可执行文件。很明显Unix链接器对输入文件在命令行中出现的顺序十分敏感，而VC的算法则可最大限度地减少文件顺序对链接的影响。作者不清楚Unix下新的开发工具是否已经改进了相应的做法，欢迎有实践经验的朋友补充这方面的信息(补充于2005年10月10日: 经试验，使用gcc 3.2.3的MinGW 3.1.0的链接器表现与参考[1]描述的一致)。

 VC带的编译器是cl.exe，它有这么几个与标准程序库有关的选项: /ML、/MLd、/MT、/MTd、/MD、/MDd。这些选项告诉编译器应用程序想使用什么版本的C标准程序库。/ML(缺省选项)对应单线程静态版的标准程序库(libc.lib)；/MT对应多线程静态版标准库(libcmt.lib)，此时编译器会自动定义_MT宏；/MD对应多线程DLL版(导入库msvcrt.lib，DLL是msvcrt.dll)，编译器自动定义_MT和_DLL 两个宏。后面加d的选项都会让编译器自动多定义一个_DEBUG宏，表示要使用对应标准库的调试版，因此/MLd对应调试版单线程静态标准库 (libcd.lib)，/MTd对应调试版多线程静态标准库(libcmtd.lib)，/MDd对应调试版多线程DLL标准库(导入库 msvcrtd.lib，DLL是msvcrtd.dll)。虽然我们的确在编译时明白无误地告诉了编译器应用程序希望使用什么版本的标准库，可是当编译器干完了活，轮到链接器开工时它又如何得知一个个目标文件到底在思念谁？为了传递相思，我们的编译器就干了点秘密的勾当。在cl编译出的目标文件中会有一个专门的区域(关心这个区域到底在文件中什么地方的朋友可以参考COFF和PE文件格式)存放一些指导链接器如何工作的信息，其中有一项就叫缺省库 (default library)，它指定了若干个库文件名，当链接器扫描该目标文件时将按照它们在目标模块中出现的顺序处理这些库名: 如果该库在当前输入文件列表中还不存在，那么便把它加入到输入文件列表末尾，否则略过。说到这里，我们先来做个小实验。写个顶顶简单的程序，然后保存为 main.c :

/* main.c */
int main() { return 0; }

用下面这个命令编译main.c(什么？你从不用命令行来编译程序？这个......) :

cl /c main.c

/c是告诉cl只编译源文件，不用链接。因为/ML是缺省选项，所以上述命令也相当于: cl /c /ML main.c 。如果没什么问题的话(要出了问题才是活见鬼！当然除非你的环境变量没有设置好，这时你应该去VC的bin目录下找到vcvars32.bat文件然后运行它。)，当前目录下会出现一个main.obj文件，这就是我们可爱的目标文件。随便用一个文本编辑器打开它(是的，文本编辑器，大胆地去做别害怕)，搜索"defaultlib"字符串，通常你就会看到这样的东西: "-defaultlib:LIBC -defaultlib:OLDNAMES"。啊哈，没错，这就
是保存在目标文件中的缺省库信息。我们的目标文件显然指定了两个缺省库，一个是单线程静态版标准库libc.lib(这与/ML选项相符)；一个是oldnames.lib(它是为了兼容微软以前的C/C++开发系统，基本不用了，为了简化讨论可以忽略它)。另外，如果在源程序中用了

/* xxxx代表实际的库文件名 */
#pragma comment(lib,"xxxx")

编译指示命令(compiler directive)指定要链接的库，那么这个信息也会被保存到目标文件的缺省库信息项中，且位于缺省标准库之前。如果有多个这样的命令，那么对应库名在目标文件中出现的顺序与它们在源程序中出现的顺序完全一致(且都在缺省标准库之前)。

 VC的链接器是link.exe，因为main.obj保存了缺省库信息，所以可以用

link main.obj libc.lib

或者

link main.obj

来生成可执行文件main.exe，这两个命令是等价的。但是如果你用

link main.obj libcd.lib

的话，链接器会给出一个警告: "warning LNK4098: defaultlib "LIBC" conflicts with use of other libs; use /NODEFAULTLIB:library"，因为你显式指定的标准库版本与目标文件的缺省值不一致。通常来说，应该保证链接器合并的所有目标文件指定的缺省标准库版本一致，否则编译器一定会给出上面的警告，而LNK2005和LNK1169链接错误则有时会出现有时不会。那么这个有时到底是什么时候？呵呵，别着急，下面的一切正是为喜欢追根究底的你准备的。

 建一个源文件，就叫mylib.c，内容如下:

/* mylib.c */
#include

void foo(void)
{
?? printf("%s","I am from mylib!\n");
}

用

cl /c /MLd mylib.c

命令编译，注意/MLd选项是指定libcd.lib为默认标准库。lib.exe是VC自带的用于将目标文件打包成程序库的命令，所以我们可以用

lib /OUT:my.lib mylib.obj

将mylib.obj打包成库，输出的库文件名是my.lib。接下来把main.c改成:

/* main.c */
void foo(void);

int main()
{
?? foo();
?? return 0;
}

用

cl /c main.c

编译，然后用

link main.obj my.lib

进行链接。这个命令能够成功地生成main.exe而不会产生 LNK2005和LNK1169链接错误，你仅仅是得到了一条警告信息:"warning LNK4098: defaultlib "LIBCD" conflicts with use of other libs; use /NODEFAULTLIB:library"。我们根据前文所述的扫描规则来分析一下链接器此时做了些啥(加一个/VERBOSE选项就可以看到详尽的链接过程，但要注意，几乎所有的C编译器都会在符号前加一个下划线后再输出，所以在目标文件和链接输出信息中看到的符号名都比在源程序中见到的多出一个 '_'，此点不可不察。)。

 一开始E、U、D都是空集。链接器首先扫描main.obj，把它的默认标准库libc.lib加入到输入文件列表末尾，它自己加入E集合，同时未解析的 foo加入U，main加入D。接着扫描my.lib，因为这是个库，所以会拿当前U中的所有符号(当然现在就一个foo)与my.lib中的所有目标模块(当然也只有一个mylib.obj)依次匹配，看是否有模块定义了U中的符号。结果mylib.obj确实定义了foo，于是它加入到E，foo从U 转移到D，未解析的printf加入到U，指定的默认标准库libcd.lib也加到输入文件列表末尾(在libc.lib之后)。不断地在my.lib 库的各模块上进行迭代以匹配U中的符号，直到U、D都不再变化。很明显，现在就已经到达了这么一个不动点，所以接着扫描下一个输入文件，就是 libc.lib。链接器发现libc.lib里的printf.obj里定义有printf，于是printf从U移到D，printf.obj加入到 E，它定义的所有符号加入到D，它里头的未解析符号加入到U。如果链接时没有指定/ENTRY(程序入口点选项)，那么链接器默认的入口点就是函数 mainCRTStartup(GUI程序的默认入口点则是WinMainCRTStartup)，它在crt0.obj中被定义，所以crt0.obj 及它直接或间接引用的模块(比如malloc.obj、free.obj等)都被加入到E中，这些目标模块指定的默认库(只crt0init.obj指定了kernel32.lib)加到输入文件列表末尾，同时更新U和D。不断匹配libc.lib中各模块直至到达不动点，然后处理libcd.lib，但是它里面的所有目标模块都没有定义U中的任何一个符号，所以链接器略过它进入到最后一个输入文件kernel32.lib。事实上，U中已有和将要加入的未解析符号都可以在其中找到定义，那么当处理完kernel32.lib时，U必然为空，于是链接器合并E中的所有模块生成可执行文件。

 上文描述了虽然各目标模块指定了不同版本的缺省标准库但仍然链接成功的例子，接下来你将目睹因为这种不严谨而导致的悲惨失败。

  修改mylib.c成这个样子:

#include

void foo(void)
{
  // just a test , don't care memory leak
 _malloc_dbg( 1, _NORMAL_BLOCK, __FILE__, __LINE__ );
}

其中_malloc_dbg不是ANSI C的标准库函数，它是VC标准库提供的malloc的调试版，与相关函数配套能帮助开发者抓各种内存错误。使用它一定要定义_DEBUG宏，否则预处理器会把它自动转为malloc。继续用

cl /c /MLd mylib.c
lib /OUT:my.lib mylib.obj

编译打包。当再次用

link main.obj my.lib

进行链接时，我们看到了什么？天哪，一堆的LNK2005加上个贵为"fatal error"的LNK1169垫底，当然还少不了那个LNK4098。链接器是不是疯了？不，你冤枉可怜的链接器了，我拍胸脯保证它可是一直在尽心尽责地照章办事。

 一开始E、U、D为空，链接器扫描main.obj，把libc.lib加到输入文件列表末尾，把main.obj加进E，把foo加进U，把main加进D。接着扫描my.lib，于是mylib.obj加入E，libcd.lib加到输入文件列表末尾，foo从U转移到D，_malloc_dbg加进 U。然后扫描libc.lib，这时会发现libc.lib里任何一个目标模块都没有定义_malloc_dbg(它只在调试版的标准库中存在)，所以不会有任何一个模块因为_malloc_dbg而加入E。但因为libc.lib中的crt0.obj定义了默认入口点函数mainCRTStartup，所以crt0.obj及它直接或间接引用的模块(比如malloc.obj、free.obj等)都被加入到E中，这些目标模块指定的默认库(只 crt0init.obj指定了kernel32.lib)加到输入文件列表末尾，同时更新U和D。不断匹配libc.lib中各模块直至到达不动点后再处理libcd.lib，发现dbgheap.obj定义了_malloc_dbg，于是dbgheap.obj加入到E，它的未解析符号加入U，它定义的所有其它符号加入D，这时灾难便来了。之前malloc等符号已经在D中(随着libc.lib里的malloc.obj加入E而加入的)，而 dbgheap.obj及因它而引入的其它模块又定义了包括malloc在内的许多同名符号，导致了重定义冲突。所以链接器在处理完所有输入文件(是的，即使中途有重定义冲突它也会处理所有的文件以便生成一个完整的冲突列表)后只好报告: 这活儿没法儿干。

  现在我们该知道，链接器完全没有责任，责任在我们自己的身上。是我们粗心地把缺省标准库版本不一致的目标文件(main.obj)与程序库 (my.lib)链接起来，引发了大灾难。解决办法很简单，要么用/MLd选项来重编译main.c；要么用/ML选项重编译mylib.c；再或者干脆在链接时用/NODEFAULTLIB:XXX选项忽略默认库XXX，但这种方法非常不保险(想想为什么？)，所以不推荐。

 在上述例子中，我们拥有库my.lib的源代码(mylib.c)，所以可以用不同的选项重新编译这些源代码并再次打包。可如果使用的是第三方的库，它并没有提供源代码，那么我们就只有改变自己程序的编译选项来适应这些库了。但是如何知道库中目标模块指定的默认库呢？其实VC提供的一个小工具便可以完成任务，这就是dumpbin.exe。运行下面这个命令

dumpbin /DIRECTIVES my.lib

然后在输出中找那些"Linker Directives"引导的信息，你一定会发现每一处这样的信息都会包含若干个类似"-defaultlib:XXXX"这样的字符串，其中XXXX便代表目标模块指定的缺省库名(注意，如果在编译时指定了/Zl选项，那么目标模块中将不会有defaultlib信息)。

 知道了第三方库指定的默认标准库，再用合适的选项编译我们的应用程序，就可以避免LNK2005和LNK1169链接错误。喜欢IDE的朋友，你一样可以到 "Project属性" -> "C/C++" -> "代码生成(code generation)" -> "运行时库(run-time library)" 项下设置应用程序的默认标准库版本，这与命令行选项的效果是一样的。

posted @ 2008-05-19 10:17 小C 阅读(2608) | 评论 (2) | 编辑 收藏

消息处理线程

DWORD MyThreadProcB(void * p)
{
 MSG msg;
 PeekMessage(&msg, NULL, WM_USER, WM_USER, PM_NOREMOVE);

 while(true)
 {
  if(GetMessage(&msg,0,0,0))
  {
   switch(msg.message)
   {
    case WM_USER + 100:
     int a = 0;
     break;
   }
  }
 };
 return 0;
}

void CmessageDlg::OnBnClickedOk()
{

 DWORD threadid;
 HANDLE patest = CreateThread(NULL,0,(LPTHREAD_START_ROUTINE)MyThreadProcB,NULL ,0,&threadid);

 Sleep(1000);
 bool a =  PostThreadMessage(threadid, WM_USER + 100, 1,2);
 OnOK();
}

posted @ 2008-03-31 15:28 小C 阅读(315) | 评论 (0) | 编辑 收藏

Tinyxml的内存析构

Tinyxml的值在使用时最好是new出来的,因为其在析构的时候会遍历整个树,将树中的节点析构掉。但是没有在树中的节点将不会被自动施放，正是这种半自动的释放带来了问题。
ReplaceChild()方法中，我们插入的值是否需要释放呢，通过查看内部的代码，它是clone一个然后加入树的，也就是说，原来的值如果是new出来就需要释放。

void set_node(TiXmlElement* element,const char* value)
{
 TiXmlText* tmp1 = new TiXmlText(value);
 TiXmlNode* node = element->FirstChild();
 if(node == NULL)
{
     element->LinkEndChild(tmp1);
} 
else
 {
     element->ReplaceChild(node,*tmp1);
     delete tmp1;
 }
}

posted @ 2008-03-31 09:58 小C 阅读(1449) | 评论 (0) | 编辑 收藏

RichEdit2.0的设置字体中Dual-font特性怎么处理

在richedit20下，设置字体为某中文字体（比如楷体），输入汉字确实是楷体，但是一旦输入英文字符（在任何位置），这些英文字符字体立即变成了Arial字体（而且有意思的是，如果再输入汉字，汉字仍然是楷体的）。

这不是bug,这是RichEdit2.0的特性。
  Dual-font:   support   The   keyboard   can   automatically   switch   fonts   when   the   active   font   is   inappropriate   for   current   keyboard,   for   example,   Kanji   characters   in   Times   New   Roman.    
  Smart   font   apply:   Font   change   request   does   not   apply   Western   fonts   to   Asian   characters.

所以，英文字体和中文字体应该分别设置，英文字体默认的就是Arial。

但是，如何将英文字体设为楷体，仍未解决。

如果有那位高手有相关处理经验，还请指教。

相关讨论
http://topic.csdn.net/t/20020731/16/913807.html#

posted @ 2008-03-24 15:25 小C 阅读(1095) | 评论 (2) | 编辑 收藏

线程间通讯

　　一般而言,应用程序中的一个次要线程总是为主线程执行特定的任务,这样,主线程和次要线程间必定有一个信息传递的渠道,也就是主线程和次要线程间要进行通信。这种线程间的通信不但是难以避免的，而且在多线程编程中也是复杂和频繁的，下面将进行说明。

1. 使用全局变量进行通信
   
   由于属于同一个进程的各个线程共享操作系统分配该进程的资源，故解决线程间通信最简单的一种方法是使用全局变量。对于标准类型的全局变量，我们建议使用volatile 修饰符，它告诉编译器无需对该变量作任何的优化，即无需将它放到一个寄存器中，并且该值可被外部改变。如果线程间所需传递的信息较复杂，我们可以定义一个结构，通过传递指向该结构的指针进行传递信息。
   　
2. 使用自定义消息
   
   我们可以在一个线程的执行函数中向另一个线程发送自定义的消息来达到通信的目的。一个线程向另外一个线程发送消息是通过操作系统实现的。利用Windows操作系统的消息驱动机制，当一个线程发出一条消息时，操作系统首先接收到该消息，然后把该消息转发给目标线程，接收消息的线程必须已经建立了消息循环。

例程7 MultiThread7

　　该例程演示了如何使用自定义消息进行线程间通信。首先，主线程向CCalculateThread线程发送消息WM_CALCULATE，CCalculateThread线程收到消息后进行计算，再向主线程发送WM_DISPLAY消息，主线程收到该消息后显示计算结果。

1. 建立一个基于对话框的工程MultiThread7，在对话框IDD_MULTITHREAD7_DIALOG中加入三个单选按钮IDC_RADIO1，IDC_RADIO2，IDC_RADIO3，标题分别为1+2+3+4+......+10，1+2+3+4+......+50，1+2+3+4+......+100。加入按钮IDC_SUM，标题为“求和”。加入标签框IDC_STATUS，属性选中“边框”；
2. 在MultiThread7Dlg.h中定义如下变量：

   protected:
       int nAddend;

   代表加数的大小。
   
   分别双击三个单选按钮，添加消息响应函数：

   void CMultiThread7Dlg::OnRadio1()
       {
       nAddend=10;
       }
       void CMultiThread7Dlg::OnRadio2()
       {
       nAddend=50;
       }
       void CMultiThread7Dlg::OnRadio3()
       {
       nAddend=100;
       }

   并在OnInitDialog函数中完成相应的初始化工作：

   BOOL CMultiThread7Dlg::OnInitDialog()
       {
       ……
       ((CButton*)GetDlgItem(IDC_RADIO1))->SetCheck(TRUE);
       nAddend=10;
       ……

   在MultiThread7Dlg.h中添加：

   #include "CalculateThread.h"
       #define WM_DISPLAY WM_USER+2
       class CMultiThread7Dlg : public CDialog
       {
       // Construction
       public:
       CMultiThread7Dlg(CWnd* pParent = NULL); // standard constructor
       CCalculateThread* m_pCalculateThread;
       ……
       protected:
       int nAddend;
       LRESULT OnDisplay(WPARAM wParam,LPARAM lParam);
       ……

   在MultiThread7Dlg.cpp中添加：

   BEGIN_MESSAGE_MAP(CMultiThread7Dlg, CDialog)
       ……
       ON_MESSAGE(WM_DISPLAY,OnDisplay)
       END_MESSAGE_MAP()
       LRESULT CMultiThread7Dlg::OnDisplay(WPARAM wParam,LPARAM lParam)
       {
       int nTemp=(int)wParam;
       SetDlgItemInt(IDC_STATUS,nTemp,FALSE);
       return 0;
       }

   以上代码使得主线程类CMultiThread7Dlg可以处理WM_DISPLAY消息，即在IDC_STATUS标签框中显示计算结果。
3. 双击按钮IDC_SUM，添加消息响应函数：

   void CMultiThread7Dlg::OnSum()
       {
       m_pCalculateThread=
       (CCalculateThread*)AfxBeginThread(RUNTIME_CLASS(CCalculateThread));
       Sleep(500);
       m_pCalculateThread->PostThreadMessage(WM_CALCULATE,nAddend,NULL);
       }

   OnSum()函数的作用是建立CalculateThread线程，延时给该线程发送WM_CALCULATE消息。
4. 右击工程并选中“New Class…”为工程添加基类为 CWinThread 派生线程类 CCalculateThread。
   
   在文件CalculateThread.h 中添加

   #define WM_CALCULATE WM_USER+1
       class CCalculateThread : public CWinThread
       {
       ……
       protected:
       afx_msg LONG OnCalculate(UINT wParam,LONG lParam);
       ……

   在文件CalculateThread.cpp中添加

   LONG CCalculateThread::OnCalculate(UINT wParam,LONG lParam)
       {
       int nTmpt=0;
       for(int i=0;i<=(int)wParam;i++)
       {
       nTmpt=nTmpt+i;
       }
       Sleep(500);
       ::PostMessage((HWND)(GetMainWnd()->GetSafeHwnd()),WM_DISPLAY,nTmpt,NULL);
       return 0;
       }
       BEGIN_MESSAGE_MAP(CCalculateThread, CWinThread)
       //{{AFX_MSG_MAP(CCalculateThread)
       // NOTE - the ClassWizard will add and remove mapping macros here.
       //}}AFX_MSG_MAP
       ON_THREAD_MESSAGE(WM_CALCULATE,OnCalculate)
       //和主线程对比，注意它们的区别
       END_MESSAGE_MAP()

   在CalculateThread.cpp文件的开头添加一条：

   #include "MultiThread7Dlg.h"

   　　以上代码为　CCalculateThread　类添加了 WM_CALCULATE 消息，消息的响应函数是 OnCalculate，其功能是根据参数 wParam 的值，进行累加，累加结果在临时变量nTmpt中，延时0.5秒，向主线程发送WM_DISPLAY消息进行显示，nTmpt作为参数传递。

编译并运行该例程,体会如何在线程间传递消息。

posted @ 2008-03-19 11:26 小C 阅读(411) | 评论 (0) | 编辑 收藏

教训

修改老代码时一定要注意不要忘记修改相关构造函数（2小时）
结构中含有string时不要用memset来初始化，会有16个字节的内存泄露（3小时）
类内变量前面要加m_,或者类内函数传递参数的命名风格要与变量名有区别,不然在多重继承的时候可能由于2者重名而产生难以发现的问题。(2小时)
结构体struct中有string时,sizeof(struct)是初始化时的大小（string为28）,其大小不随string改变而改变,所以如果string比较大（16个字节以上）,用sizeof会出现问题。（2小时）

posted @ 2008-03-17 12:12 小C 阅读(387) | 评论 (0) | 编辑 收藏

拷贝构造和赋值函数(pushback调用拷贝构造函数)

pushback并非调用赋值函数,而是调用拷贝构造函数
RoleBasicInfo & operator =(const RoleBasicInfo & tmprolebasicinfo);
(非 RoleBasicInfo & operator =(RoleBasicInfo & tmprolebasicinfo);)
db_friend_t::db_friend_t(const db_friend_t & tmpdftinfo);

推测强制类型转换调用的也是拷贝构造,结束时析构.

class A
{}

A a;
A b = a;//拷贝构造函数;
A c;
c = a; //赋值函数;
所以写赋值函数时顺便写拷贝构造函数.

A a;
A b;
b = (A)a;
先copy构造一个,然后用赋值赋给b
http://www.vckbase.com/document/viewdoc/?id=1532

posted @ 2008-03-17 11:30 小C 阅读(774) | 评论 (0) | 编辑 收藏