通常，在模块的头文件中对本模块提供给其它模块引用的函数和全局变量以关键字include声明。例如，如果模块B欲引用该模块A中定义的全局变量和函数时只需包含模块A的头文件即可。这样，模块B中调用模块A中的函数时，在编译阶段，模块B虽然找不到该函数，但是并不会报错；它会在连接阶段中从模块A编译生成的目标代码中找到此函数。
作为一种面向对象的语言，C++支持函数重载，而过程式语言C则不支持。函数被C++编译后在符号库中的名字与C语言的不同。
例如，假设某个函数的原型为： void foo( int x, int y );
该函数被C编译器编译后在符号库中的名字为_foo，而C++编译器则会产生像_foo_int_int之类的名字（不同的编译器可能生成的名字不同，但是都采用了相同的机制，生成的新名字称为“mangled name”）。
_foo_int_int这样的名字包含了函数名、函数参数数量及类型信息，C++就是靠这种机制来实现函数重载的。例如，在C++中，函数void foo( int x, int y )与void foo( int x, float y )编译生成的符号是不相同的，后者为_foo_int_float。
同样地，C++中的变量除支持局部变量外，还支持类成员变量和全局变量。用户所编写程序的类成员变量可能与全局变量同名，我们以"."来区分。而本质上，编译器在进行编译时，与函数的处理相似，也为类中的变量取了一个独一无二的名字，这个名字与用户程序中同名的全局变量名字不同。
extern "C"是连接申明(linkage declaration),被extern "C"修饰的变量和函数是按照C语言方式编译和连接的。
(1)未加extern "C"声明时的连接方式
假设在C++中，模块A的头文件如下：
// 模块A头文件 moduleA.h
int foo( int x, int y );
在模块B中引用该函数：
// 模块B实现文件 moduleB.cpp
＃include "moduleA.h"
foo(2,3);
在连接阶段，连接器会从模块A生成的目标文件moduleA.obj中寻找_foo_int_int这样的符号！
(2)加extern "C"声明后的编译和连接方式
加extern "C"声明后，模块A的头文件变为：
// 模块A头文件 moduleA.h
extern "C" int foo( int x, int y );
在模块B的实现文件中仍然调用foo( 2,3 )，其结果是：
（1）模块A编译生成foo的目标代码时，没有对其名字进行特殊处理，采用了C语言的方式；
（2）连接器在为模块B的目标代码寻找foo(2,3)调用时，寻找的是未经修改的符号名_foo。
如果在模块A中函数声明了foo为extern "C"类型，而模块B中包含的是extern int foo( int x, int y ) ，则模块B找不到模块A中的函数；反之亦然。所以，可以用一句话概括extern “C”这个声明的真实目的：实现C++与C及其它语言的混合编程。
extern "C"通常的使用技巧和惯用法：
（1）在C++中引用C语言中的函数和变量，在包含C语言头文件（假设为cExample.h）时，需进行下列处理：
extern "C"
{
＃include "cExample.h"
}
而在C语言的头文件中，对其外部函数只能指定为extern类型，C语言中不支持extern "C"声明，在.c文件中包含了extern "C"时会出现编译语法错误。
如果C++调用一个C语言编写的.DLL时，当包括.DLL的头文件或声明接口函数时，应加extern "C" { }。
（2）在C中引用C++语言中的函数和变量时，C++的头文件需添加extern "C"，但是在C语言中不能直接引用声明了extern "C"的该头文件，应该仅将C文件中将C++中定义的extern "C"函数声明为extern类型。
1、SendMessage、PostMessage的运行机制
SendMessage可以理解为，SendMessage函数发送消息，等待消息处理完成后，SendMessage才返回。稍微深入一点，是等待窗口处理函数返回后，SendMessage就返回了。
PostMessage可以理解为，PostMessage函数发送消息，不等待消息处理完成，立刻返回。稍微深入一点，PostMessage只管发送消息，消息有没有被送到则并不关心，只要发送了消息，便立刻返回。
对于写一般Windows程序的程序员来说，能够这样理解也就足够了。
2、GetMessage()和PeekMessage()有什么区别？
GetMessage(LPMSG lpMsg, HWND hWnd, UINT wMsgFilterMin, UINT wMsgFilterMax)
PeekMessage(LPMSG lpMsg, HWND hWnd, UINT wMsgFilterMin, UINT wMsgFilterMax,UINT wRemoveMsg)
参数wRemoveMsg的作用是指定消息获取的方式，如果设为PM_NOREMOVE,那么消息将不会从消息队列中被移出，如果设为PM_REMOVE，那么消息将会从消息队列中被移出；
两个函数主要有以下两个区别:
1.GetMessage将等到有合适的消息时才返回,而PeekMessage只是撇一下消息队列。
2.GetMessage会将消息从队列中删除,而PeekMessage可以设置最后一个参数wRemoveMsg来决定是否将消息保留在队列中。
在Windows的内部，GetMessage和PeekMessage执行着相同的代码。而两者最大的不同之处则体现在没有任何消息返回到应用程序的情况下。在此种情况下，PeekMessage会返回一个空值到应用程序，GetMessage会在此时让应用程序休眠。
举例说明Windows中有哪些同步对象（或锁），在什么情况下使用这些同步对象？
在windows平台下，用于对多线程（包括进程）之间的同步保护机制，基本上有这么几种：
1）Critical Section对象（临界区） 2）Event对象（事件） 3）Mutex对象（互斥量） 4） Semaphore对象（信号量）。
本文的着眼点在于：总结出这些同步保护机制的一些明显的行为特征。
以下我们所讨论的这些行为特征，是对并发的进/线程之间的同步保护机制的一般描述，本文用windows平台作为一个典型的例子。 基于这一些行为特征，对本文提及的这四种同步对象做一个分类。
另外，在这里，我们把这四种同步对象，统统称为“锁”，以便于接下来的讨论。
第一、保护与同步。
在这里要强调的是：保护与同步是两个不同的概念。而我们经常会混合这两个概念。保护是指在多线程的环境下对共享资源的保护。这样的共享资源大多数情况下是一段内存块，它会被很多线程试图访问和修改。而同步更多的强调的是线程之间的协作，协同工作是需要同步支持的。
基于这一性质，我们可以看出：Critical Section对象其本质更多的强调的是保护，而Event对象、Mutex对象与Semaphore对象更多的强调的是同步。不过，这样的区别，只是概念上的区别，其本身不会对程序本身产生影响。
第二、锁的等待超时
在开发并发的多进/线程程序时，为了避免死锁之类的问题，引入了“等超时“的概念，即当一个线程需要获得一个锁来执行某些代码的时候，它可以在所等待的锁上设置超时值。如果在确定的时间（超时值）内无法获得该锁，它可以选择放弃执行该段代码的权利，这样可以在一定程度上避免出现死锁的问题。这就是锁的等待超时的基本含义。基于这一行为特征，我们来对上面四种同步对象做一个划分：Critical Section对象是无法设置等待超时的，而其他三个对象则可以设置等待超时。从这一点来讲，在使用Critical Section对象时，由于在等待进入关键代码段时无法设置等待超时，很容易造成死锁。
第三、线程锁与进程锁
这里所说的线程锁指的是该锁只在一个进程的所有线程中可见，而进程锁指的是该锁可以被不同的进程所访问，可用于进程间的同步与互斥。当然进程锁仍然可以被用于同一个进程的不同线程之间的同步与互斥。进程锁的概念是大于线程锁的。基于这一特点划分的话，Critical Section对象是线程锁，而其他三个对象是进程锁。这一点从本质上来分析，Critical Section对象是用户态模式下面实现线程同步的方法，而其他三个对象均是内核对象。内核对象机制的适应性远远优于用户方式机制。实际上，内核对象机制的唯一不足之处在于它的速度比较慢，这是因为当调用内核机制对象时，必须从用户方式转到内核方式。这样的转换需要付出很大的代价，是一件很费时的操作。在X86平台上,这样往返一次需要占用1000个CPU周期(这并不包括执行内核方式的代码)。当然需要注意的是：使用Critical Section对象并不意味着线程不会陷入核心态执行。当一个线程试图进入另一个线程拥有的关键代码段时,该线程就会进入等待状态。这意味着：该线程必须从用户态转为核心态。(为了提高这一方面的性能,Microsoft将循环锁的概念纳入到了Critical Section对象中,该线程可以有选择地不进入核心态等待.具体请参阅MSDN)
第四、锁的递归特质
所谓递归锁指的是当一个线程拥有一个同步锁时,而递归地想再次取得该锁.如果这次获得操作不会阻塞当前线程的执行,则称该锁为递归锁.递归锁主要是在"保护"的概念上提出的,而"保护"概念下的锁包括Critical Section对象和Mutext 对象.这两种锁在Windows平台上都是递归锁。需要注意的是：调用线程获得几次递归锁必须释放几次递归锁。
第五、读写锁
读写锁允许高效的并发的访问多线程环境下的共享资源。对于一种共享资源,多个线程可以获得读锁,共享地读该共享资源。而在同一时刻,只允许一个线程拥有写锁改变该共享资源.这就是读写锁的概念。很遗憾的是在Windows平台上没有这样的读写锁,你需要自己去实现。
2221
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
