{

byte a[4];// 每一个字节赋数值类型

byte c1[4];

byte c2[4];

memcpy(c1, a, sizeof(byte)*4); //正确使用

strcpy((char*)(byte*)c2, (char*)(byte*)a);//错误调用

}

函数原型

   strcpy

   extern char *strcpy(char *dest,char *src);

   #include <string.h>

   功能：把src所指由NULL结束的字符串复制到dest所指的数组中

   说明:src和dest所指内存区域不可以重叠且dest必须有足够的空间来容纳src的字符串。

   返回指向dest的指针



  memcpy

  extern void *memcpy(void *dest,void *src,unsigned int count);

  #include <string.h>

   功能：由src所指内存区域复制count个字符串到dest所指内存区域.

   说明：src和dest所指内存区域不能重叠，函数返回指向dest的指针.函数原型

 

关于memcpy的用法

作用：在dest处拷贝src处的字节，并以count来计算需要拷贝的字节数量，进行内存的拷贝。

参数： dest:新的存贮区的开始部位   src：需要拷贝的开始部位    count：需要拷贝的字节数备注：dest,src，它们都是从各自的地址处进行写入，如果是p而不是&p,那么奖会取得p的值（地址）,在该值的地址处进行读出或写入。

例：  

int* intPoint = new int(3333);  

int* intPoint1;  

//在intPoint1的地址处写入intPoint地址处的值，也就是intPoint指针值。 

memcpy( &intPoint1, &intPoint, 4 );

//使intPoint1指向了intPoint. 或   int* intPoint = new int(3333);

cout << *intPoint1 << endl;

可以看出　strcpy()　是处理的字符串(遇零结束)，memcpy()　是处理一个缓冲区（void*类型的），而我们的内容中有数字0，而数字0又是字符串的结尾字符 ' \0' 的数字表现，字符串拷贝是遇到0就结束，所以，如果要拷贝的缓冲区如果是非字符串那么就尽量用memcpy()，这样可以避免出错的可能。

Visual Studio 2005把泛型编程的类型参数模型引入了微软.NET框架组件。C++/CLI支持两种类型参数机制--通用语言运行时（CLR）泛型和C++模板。本文将介绍两者之间的一些区别--特别是参数列表和类型约束模型之间的区别。

　　参数列表又回来了

　　参数列表与函数的信号（signature）类似：它标明了参数的数量和每个参数的类型，并把给每个参数关联一个唯一的标识符，这样在模板定义的内部，每个参数就可以被唯一地引用。

　　参数在模板或泛型的定义中起占位符（placeholder）的作用。用户通过提供绑定到参数的实际值来建立对象实例。参数化类型的实例化并非简单的文本替代（宏扩展机制就是使用文本替代的）。相反地，它把实际的用户值绑定到定义中的相关的形式参数上。

　　在泛型中，每个参数都表现为Object类型或衍生自Object的类型。在本文后面你可以看到，这约束了你可能执行的操作类型或通过类型参数声明的对象。你可以通过提供更加明确的约束来调整这些约束关系。这些明确的约束引用那些衍生出实际类型参数的基类或接口集合。

　　模板除了支持类型参数之外，还支持表达式和模板参数。此外，模板还支持默认的参数值。这些都是按照位置而不是名称来分解的。在两种机制之下，类型参数都是与类或类型名称关键字一起引入的。

　　参数列表的额外的模板功能

　　模板作为类型参数的补充，允许两种类型的参数：非类型（non-type）参数和模板参数。我们将分别简短地介绍一下。

　　非类型参数受常数表达式的约束。我们应该立即想到它是数值型或字符串常量。例如，如果选择提供固定大小的堆栈，你就可能同时指定一个非类型的大小参数和元素类型参数，这样就可以同时按照元素类别和大小来划分堆栈实例的类别。例如，你可以在代码1中看到带有非类型参数的固定大小的堆栈。

　　代码1：带有非类型固定大小的堆栈

template <class elemType, int size>
public ref class tStack
{
　array<elemType> ^m_stack;
　int top;

　public:
　　tStack() : top( 0 )
　　{ m_stack = gcnew array<elemType>( size ); }
};
　　此外，如果模板类设计者可以为每个参数指定默认值，使用起来就可能方便多了。例如，把缓冲区的默认大小设置为1KB就是很好的。在模板机制下，可以给参数提供默认值，如下所示：

// 带有默认值的模板声明
template <class elemType, int size = 1024>
public ref class FixedSizeStack {};
　　用户可以通过提供明确的第二个值来重载默认大小值：

// 最多128个字符串实例的堆栈
FixedSizeState<String^, 128> ^tbs = gcnew FixedSizeStack<String^, 128>;
　　否则，由于没有提供第二个参数，它使用了相关的默认值，如下所示：

// 最多1024个字符串实例的堆栈
FixedSizeStack<String^> ^tbs = gcnew FixedSizeStack<String^>;
　　使用默认的参数值是标准模板库（STL）的一个基本的设计特征。例如，下面的声明就来自ISO-C++标准：

// ISO-C++名字空间std中的默认类型参数值示例
{
　template <class T, class Container = deque<T> >
　class queue;

　template <class T, class Allocator = allocator<T> >
　class vector;
　// ...
}
　　你可以提供默认的元素类型，如下所示：

// 带有默认的元素类型的模板声明
template <class elemType=String^, int size=1024>
public ref class tStack {};

　　从设计的角度来说很难证明它的正确性，因为一般来说容器不会集中在在单个默认类型上。

　　指针也可以作为非类型参数，因为对象或函数的地址在编译时就已知了，因此是一个常量表达式。例如，你可能希望为堆栈类提供第三个参数，这个参数指明遇到特定条件的时候使用的回调处理程序。明智地使用typedef可以大幅度简化那些表面上看起来很复杂的声明，如下所示：

typedef void (*handler)( ... array<Object^>^ );
template <class elemType, int size, handler cback >
public ref class tStack {};
　　当然，你可以为处理程序提供默认值--在这个例子中，是一个已有的方法的地址。例如，下面的缓冲区声明就提供了大小和处理程序：

void defaultHandler( ... array<Object^>^ ){ ... }

template < class elemType,
int size = 1024,
handler cback = &defaultHandler >
public ref class tStack {};
　　由于默认值的位置次序优先于命名次序，因此如果不提供明确的大小值（即使这个大小与默认值是重复的），就无法提供重载的处理程序的。下面就是可能用到的修改堆栈的方法：

void demonstration()
{
　// 默认的大小和处理程序
　tStack<String^> ^ts1 = nullptr;
　// 默认的处理程序
　tStack<String^, 128> ^ts2 = gcnew tStack<String^, 128>;
　// 重载所有的三个参数
　tStack<String^, 512, &yourHandler> ^ts3;
}

　　模板支持的第二种额外的参数就是template模板参数--也就是这个模板参数本身表现为一个模板。例如：

// template模板参数
template <template <class T> class arena, class arenaType>
class Editor {
arena<arenaType> m_arena;
// ...
};
　　Editor模板类列出了两个模板参数arena和arenaType。ArenaType是一个模板类型参数；你可以传递整型、字符串型、自定义类型等等。Arena是一个template模板参数。带有单个模板类型参数的任何模板类都可以绑定到arena。m_arena是一个绑定到arenaType模板类型参数的模板类实例。例如：

// 模板缓冲区类
template <class elemType>
public ref class tBuffer {};

void f()
{
　Editor<tBuffer,String^> ^textEditor;
　Editor<tBuffer,char> ^blitEditor;
　// ...
}

　　类型参数约束

　　如果你把参数化类型简单地作为存储和检索元素的容器，那么你可以略过这一部分了。当你需要调用某个类型参数（例如在比较两个对象，查看它们相等或者其中一个小于另一个的时候，或者通过类型参数调用方法名称或嵌套类型的时候）上的操作的时候，才会考虑约束的问题。例如：

template <class T>
ref class Demonstration {
　int method() {
　　typename T::A *aObj;
　　// ...
　}
};

　　这段代码成功地声明了aObj，它同时还约束了能够成功地绑定到你的类模板的类型参数。例如，如果你编写下面的代码，aObj的声明就是非法的（在这种特定的情况下），编译器会报错误信息：

int demoMethod()
{
　Demonstration<int> ^demi = gcnew Demonstration<int>( 1024 );
　return dm->method();
}

　　当然，其特定的约束是，这个类型参数必须包含一个叫做A的类型的嵌套声明。如果它的名字叫做B、C或Z都没有关系。更普通的约束是类型参数必须表示一个类，否则就不允许使用T::范围操作符。我使用int类型参数同时违反了这两条约束。例如，Visual C++编译器会生成下面的错误信息：

error C2825: 'T': must be a class or namespace when followed by '::'

　　C++模板机制受到的一条批评意见是：缺乏用于描述这种类型约束的形式语法（请注意，在参数化类型的原始设计图纸中，Bjarne Stroustrup论述了曾经考虑过提供显式约束语法，但是他对这种语法不太满意，并选择了在那个时候不提供这种机制）。也就是说，在一般情况下，用户在阅读源代码或相关的文档，或者编译自己的代码并阅读随后的编译器错误消息的时候，才能意识到模板有隐含约束。

　　如果你必须提供一个与模板不匹配的类型参数该怎么办呢？一方面，我们能做的事情很少。你编写的任何类都有一定的假设，这些假设表现为某些使用方面的约束。很难设计出适合每种情况的类；设计出适合每种情况和每种可能的类型参数的模板类更加困难。

　　另一方面，存在大量的模板特性为用户提供了"迂回"空间。例如，类模板成员函数不会绑定到类型参数，直到在代码中使用该函数为止（这个时候才绑定）。因此，如果你使用模板类的时候，没有使用那些使类型参数失效的方法，就不会遇到问题。

　　如果这样也不可行，那么还可以提供该方法的一个专门的版本，让它与你的类型参数关联。在这种情况下，你需要提供Demonstration<int>::方法的一个专用的实例，或者，更为普遍的情况是，在提供整数类型参数的时候，提供整个模板类的专门的实现方式。

　　一般来说，当你提到参数化类型可以支持多种类型的时候，你一般谈到的是参数化的被动使用--也就是说，主要是类型的存储和检索，而不是积极地操作（处理）它。

　　作为模板的设计人员，你必须知道自己的实现对类型参数的隐含约束条件，并且努力去确保这些条件不是多余的。例如，要求类型参数提供等于和小于操作是合理的；但是要求它支持小于或等于或XOR位运算符就不太合理了。你可以通过把这些操作分解到不同的接口中，或者要求额外的、表示函数、委托或函数对象的参数来放松对操作符的依赖性。例如，代码2显示了一个本地C++程序员使用内建的等于操作符实现的搜索方法。

　　代码2：不利于模板的搜索实现

template <class elemType, int size=1024>
ref class Container
{
　array<elemType> ^m_buf;
　int next;

　public:
　　bool search( elemType et )
　　{
　　　for each ( elemType e in m_buf )
　　　　if ( et == e )
　　　　　return true;
　　　　return false;
　　}

　　Container()
　　{
　　　m_buf = gcnew array<elemType>(size);
　　　next = 0;
　　}

　　void add( elemType et )
　　{
　　　if ( next >= size )
　　　　throw gcnew Exception;
　　　　m_buf[ next++ ] = et;
　　}

　　elemType get( int ix )
　　{
　　　if ( ix < next )
　　　　return m_buf[ ix ];
　　　throw gcnew Exception;
　　}
　　// ...
　};

　　在这个搜索函数中没有任何错误。但是，它不太利于使用模板，因为类型参数与等于操作符紧密耦合了。更为灵活的方案是提供第二个搜索方法，允许用户传递一个对象来进行比较操作。你可以使用函数成员模板来实现这个功能。函数成员模板提供了一个额外的类型参数。请看一看代码3。

　　代码3：使用模板

template <class elemType, int size=1024>
ref class Container
{
　// 其它的都相同 ...
　// 这是一个函数成员模板...
　// 它可以同时引用包含的类参数和自有参数...

　template <class Comparer>
　bool search( elemType et, Comparer comp )
　{
　　for each ( elemType e in m_buf )
　　　if ( comp( et, e ) )
　　　　return true;
　
　　　return false;
　}
　// ...
};

　　现在用户可以选择使用哪一个方法来搜索内容了：紧密耦合的等于操作符搜索效率较高，但是不适合于所有类型；较灵活的成员模板搜索要求传递用于比较的类型。

　　哪些对象适用这种比较目的？函数对象就是普通的用于这种目的的C++设计模式。例如，下面就是一个比较两个字符串是否相等的函数对象：

class EqualGuy {
　public:
　　bool operator()( String^ s1, String^ s2 )
　　{
　　　return s1->CompareTo( s2 ) == 0;
　　}
};

　　代码4中的代码显示了你如何调用这两个版本的搜索成员函数模板和传统的版本。

　　代码4：两个搜索函数

int main()
{
　Container<String^> ^sxc = gcnew Container<String^>;
　sxc->add( "Pooh" );
　sxc->add( "Piglet" );

　// 成员模板搜索 ...
　if ( sxc->search( "Pooh", EqualGuy() ) )
　　Console::WriteLine( "found" );
　else Console::WriteLine( "not found" );

　　// 传统的等于搜索 ...
　　if ( sxc->search( "Pooh" ) )
　　　Console::WriteLine( "found" );
　　else Console::WriteLine( "not found" );
}

　　一旦有了模板的概念，你就会发现使用模板几乎没有什么事情不是实现。至少感觉是这样的。

generic <class elemType>
public ref class Container
{
　array<elemType> ^m_buf;
　int next;
　int size;
　
public:
　bool search( elemType et )
　{
　　for each ( elemType e in m_buf )
　　　if ( et->CompareTo( e ))
　　　　return true;
　　　return false;
　}

　Container( int sz )
　{
　　m_buf = gcnew array<elemType>(size = sz);
　　next = 0;
　}

　// add() 和 get() 是相同的 ...

};

　　该泛型类的实现在编译的时候失败了，遇到了如下所示的致命的编译诊断信息：

error C2039: 'CompareTo' : is not a member of 'System::Object'

　　你也许有点糊涂了，这是怎么回事？没有人认为它是System::Object的成员啊。但是，在这种情况下你就错了。在默认情况下，泛型参数执行最严格的可能的约束：它把自己的所有类型约束为Object类型。这个约束条件是对的，因为只允许CLI类型绑定到泛型上，当然，所有的CLI类型都多多少少地衍生自Object。因此在默认情况下，作为泛型的作者，你的操作非常安全，但是可以使用的操作也是有限的。

　　你可能会想，好吧，我减小灵活性，避免编译器错误，用等于操作符代替CompareTo方法，但是它却引起了更严重的错误：

error C2676: binary '==' : 'elemType' does not define this operator
or a conversion to a type acceptable to the predefined operator

　　同样，发生的情况是，每个类型参数开始的时候都被Object的四个公共的方法包围着：ToString、GetType、GetHashCode和Equals。其效果是，这种在单独的类型参数上列出约束条件的工作表现了对初始的强硬约束条件的逐步放松。换句话说，作为泛型的作者，你的任务是按照泛型约束列表的约定，采用可以验证的方式来扩展那些允许的操作。我们来看看如何实现这样的事务。

　　我们用约束子句来引用约束列表，使用非保留字"where"实现。它被放置在参数列表和类型声明之间。实际的约束包含一个或多个接口类型和/或一个类类型的名称。这些约束显示了参数类型希望实现的或者衍生出类型参数的基类。每种类型的公共操作集合都被添加到可用的操作中，供类型参数使用。因此，为了让你的elemType参数调用CompareTo，你必须添加与Icomparable接口关联的约束子句，如下所示：

generic <class elemType>
where elemType : IComparable
public ref class Container
{
　// 类的主体没有改变 ...
};

　　这个约束子句扩展了允许elemType实例调用的操作集合，它是隐含的Object约束和显式的Icomparable约束的公共操作的结合体。该泛型定义现在可以编译和使用了。当你指定一个实际的类型参数的时候（如下面的代码所示），编译器将验证实际的类型参数是否与将要绑定的类型参数的约束相匹配：

int main()
{
　// 正确的：String和int实现了IComparable
　Container<String^> ^sc;
　Container<int> ^ic;

　//错误的：StringBuilder没有实现IComparable
　Container<StringBuilder^> ^sbc;
}

　　编译器会提示某些违反了规则的信息，例如sbc的定义。但是泛型的实际的绑定和构造已经由运行时完成了。

　　接着，它会同时验证泛型在定义点（编译器处理你的实现的时候）和构造点（编译器根据相关的约束条件检查类型参数的时候）是否违反了约束。无论在那个点失败都会出现编译时错误。

　　约束子句可以每个类型参数包含一个条目。条目的次序不一定跟参数列表的次序相同。某个参数的多个约束需要使用逗号分开。约束在与每个参数相关的列表中必须唯一，但是可以出现在多个约束列表中。例如：

generic <class T1, class T2, class T3>
where T1 : IComparable, ICloneable, Image
where T2 : IComparable, ICloneable, Image
where T3 : ISerializable, CompositeImage
public ref class Compositor
{
　// ...
};

　　在上面的例子中，出现了三个约束子句，同时指定了接口类型和一个类类型（在每个列表的末尾）。这些约束是有额外的意义的，即类型参数必须符合所有列出的约束，而不是符合它的某个子集。我的同事Jon Wray指出，由于你是作为泛型的作者来扩展操作集合的，因此如果放松了约束条件，那么该泛型的用户在选择类型参数的时候就得增加更多的约束。

　　T1、T2和T3子句可以按照其它的次序放置。但是，不允许跨越两个或多个子句指定某个类型参数的约束列表。例如，下面的代码就会出现违反语法错误：

generic <class T1, class T2, class T3>
// 错误的：同一个参数不允许有两个条目
where T1 : IComparable, ICloneable
where T1 : Image
public ref class Compositor
{
　// ...
};

　　类约束类型必须是未密封的（unsealed）参考类（数值类和密封类都是不允许的，因为它们不允许继承）。有四个System名字空间类是禁止出现在约束子句中的，它们分别是：System::Array、System::Delegate、 System::Enum和System::ValueType。由于CLI只支持单继承（single inheritance），约束子句只支持一个类类型的包含。约束类型至少要像泛型或函数那样容易访问。例如，你不能声明一个公共泛型并列出一个或多个内部可视的约束。

　　任何类型参数都可以绑定到一个约束类型。下面是一个简单的例子：

generic <class T1, class T2>
where T1 : IComparable<T1>
where T2 : IComparable<T2>
public ref class Compositor
{
　// ...
};

　　约束是不能继承的。例如，如果我从Compositor继承得到下面的类，Compositor的T1和T2上的Icomparable约束不会应用在 BlackWhite_Compositor类的同名参数上：

generic <class T1, class T2>
public ref class BlackWhite_Compositor : Compositor
{
　// ...
};

　　当这些参数与基类一起使用的时候，这就有几分设计方面的便利了。为了保证Compositor的完整性，BlackWhite_Compositor必须把Compositor约束传播给那些传递到Compositor子对象的所有参数。例如，正确的声明如下所示：

generic <class T1, class T2>
where T1 : IComparable<T1>
where T2 : IComparable<T2>
public ref class BlackWhite_Compositor : Compositor
{
　// ...
};

　　包装

　　你已经看到了，在C++/CLI下面，你可以选择CLR泛型或C++模板。现在你所拥有的知识已经可以根据特定的需求作出明智的选择了。在两种机制下，超越元素的存储和检索功能的参数化类型都包含了每种类型参数必须支持操作的假设。

　　使用模板的时候，这些假设都是隐含的。这给模板的作者带来了很大的好处，他们对于能够实现什么样的功能有很大的自由度。但是，这对于模板的使用者是不利的，他们经常面对某些可能的类型参数上的没有正式文档记载的约束集合。违反这些约束集合就会导致编译时错误，因此它对于运行时的完整性不是威胁，模板类的使用可以阻止失败出现。这种机制的设计偏好倾向于实现者。

　　使用泛型的时候，这些假设都被明显化了，并与约束子句中列举的基本类型集合相关联。这对泛型的使用者是有利的，并且保证传递给运行时用于类型构造的任何泛型都是正确的。据我看来，它在设计的自由度上有一些约束，并且使某些模板设计习惯稍微难以受到支持。对这些形式约束的违反，无论使在定义点还是在用户指定类型参数的时候，都会导致编译时错误。这种机制的设计偏好倾向于消费者。

　　从设计的角度来说很难证明它的正确性，因为一般来说容器不会集中在在单个默认类型上。

　　指针也可以作为非类型参数，因为对象或函数的地址在编译时就已知了，因此是一个常量表达式。例如，你可能希望为堆栈类提供第三个参数，这个参数指明遇到特定条件的时候使用的回调处理程序。明智地使用typedef可以大幅度简化那些表面上看起来很复杂的声明，如下所示：

深入探讨MFC消息循环和消息泵

作者：周焱

首 先，应该清楚MFC的消息循环(::GetMessage,::PeekMessage)，消息泵(CWinThread::PumpMessage)和 MFC的消息在窗口之间的路由是两件不同的事情。在MFC的应用程序中(应用程序类基于CWinThread继承)，必须要有一个消息循环，他的作用是从 应用程序的消息队列中读取消息，并把它派送出去(::DispatchMessage)。而消息路由是指消息派送出去之后，系统(USER32.DLL) 把消息投递到哪个窗口，以及以后消息在窗口之间的传递是怎样的。

消息分为队列消息(进入线程的消息队列) 和非队列消息(不进入线程的消息队列)。对于队列消息，最常见的是鼠标和键盘触发的消息，例如WM_MOUSERMOVE,WM_CHAR等消息；还有例 如：WM_PAINT、WM_TIMER和WM_QUIT。当鼠标、键盘事件被触发后，相应的鼠标或键盘驱动程序就会把这些事件转换成相应的消息，然后输 送到系统消息队列，由Windows系统负责把消息加入到相应线程的消息队列中，于是就有了消息循环(从消息队列中读取并派送消息)。还有一种是非队列消 息，他绕过系统队列和消息队列，直接将消息发送到窗口过程。例如,当用户激活一个窗口系统发送WM_ACTIVATE, WM_SETFOCUS, and WM_SETCURSOR。创建窗口时发送WM_CREATE消息。在后面你将看到，MS这么设计是很有道理的，以及他的整套实现机制。

这里讲述MFC的消息循环，消息泵。先看看程序启动时，怎么进入消息循环的：
_tWinMain ->AfxWinMain ->AfxWinInit ->CWinThread::InitApplication ->CWinThread::InitInstance ->CWinThread::Run

非对话框程序的消息循环的事情都从这CWinThread的一Run开始...

第一部分：非对话框程序的消息循环机制。

//thrdcore.cpp
// main running routine until thread exits
int CWinThread::Run()
{
ASSERT_VALID(this);

// for tracking the idle time state
BOOL bIdle = TRUE;
LONG lIdleCount = 0;

// acquire and dispatch messages until a WM_QUIT message is received.
for (;;)
{
// phase1: check to see if we can do idle work
while (bIdle &&
   !::PeekMessage(&m_msgCur, NULL, NULL, NULL, PM_NOREMOVE))
{
   // call OnIdle while in bIdle state
   if (!OnIdle(lIdleCount++))
    bIdle = FALSE; // assume "no idle" state
}

// phase2: pump messages while available
do
{
   // pump message, but quit on WM_QUIT
   if (!PumpMessage())
    return ExitInstance();

   // reset "no idle" state after pumping "normal" message
   if (IsIdleMessage(&m_msgCur))
   {
    bIdle = TRUE;
    lIdleCount = 0;
   }

} while (::PeekMessage(&m_msgCur, NULL, NULL, NULL, PM_NOREMOVE));
}    //无限循环，退出条件是收到WM_QUIT消息。

ASSERT(FALSE); // not reachable
}

这是一个无限循环，他的退出条件是收到WM_QUIT消息：

if (!PumpMessage())
    return ExitInstance();

在PumpMessage中，如果收到WM_QUIT消息，那么返回FALSE,所以ExitInstance()函数执行，跳出循环，返回程序的退出代码。所以，一个程序要退出，只用在代码中调用函数

VOID PostQuitMessage( int nExitCode )。指定退出代码nExitCode就可以退出程序。

下面讨论一下这个函数Run的流程，分两步：

1, 第一个内循环phase1。bIdle代表程序是否空闲。他的意思就是，如果程序是空闲并且消息队列中没有要处理的消息，那么调用虚函数OnIdle进行 空闲处理。在这个处理中将更新UI界面(比如工具栏按钮的enable和disable状态)，删除临时对象(比如用FromHandle得到的对象指 针。由于这个原因，在函数之间传递由FromHandle得到的对象指针是不安全的，因为他没有持久性)。OnIdle是可以重载的，你可以重载他并返回 TRUE使消息循环继续处于空闲状态。

NOTE：MS用临时对象是出于效率上的考虑，使内存 有效利用，并能够在空闲时自动撤销资源。关于由句柄转换成对象，可以有若干种方法。一般是先申明一个对象obj,然后使用obj.Attatch来和一个 句柄绑定。这样产生的对象是永久的，你必须用obj.Detach来释放对象。

2，第二个内循环phase2。在这个循环内先启动消息泵(PumpMessage),如果不是WM_QUIT消息，消息泵将消息发送出去(::DispatchMessage)。消息的目的地是消息结构中的hwnd字段所对应的窗口。
//thrdcore.cpp
BOOL CWinThread::PumpMessage()
{
ASSERT_VALID(this);

//如果是WM_QUIT就退出函数(return FALSE)，这将导致程序结束.
if (!::GetMessage(&m_msgCur, NULL, NULL, NULL)) {
#ifdef _DEBUG
   if (afxTraceFlags & traceAppMsg)
    TRACE0("CWinThread::PumpMessage - Received WM_QUIT.\n");
   m_nDisablePumpCount++; // application must die
    // Note: prevents calling message loop things in 'ExitInstance'
    // will never be decremented
#endif
   return FALSE;
}

#ifdef _DEBUG
if (m_nDisablePumpCount != 0)
{
   TRACE0("Error: CWinThread::PumpMessage called when not permitted.\n");
   ASSERT(FALSE);
}
#endif

#ifdef _DEBUG
if (afxTraceFlags & traceAppMsg)
   _AfxTraceMsg(_T("PumpMessage"), &m_msgCur);
#endif

// process this message

if (m_msgCur.message != WM_KICKIDLE && !PreTranslateMessage(&m_msgCur))
{
   ::TranslateMessage(&m_msgCur); //键转换
   ::DispatchMessage(&m_msgCur); //派送消息
}
return TRUE;
}

在 这一步有一个特别重要的函数大家一定认识：PreTranslateMessage。这个函数在::DispatchMessage发送消息到窗口之前， 进行对消息的预处理。PreTranslateMessage函数是CWinThread的成员函数，大家重载的时候都是在View类或者主窗口类中，那 么，它是怎么进入别的类的呢？代码如下：
//thrdcore.cpp
BOOL CWinThread::PreTranslateMessage(MSG* pMsg)
{
ASSERT_VALID(this);

// 如果是线程消息，那么将会调用线程消息的处理函数
if (pMsg->hwnd == NULL && DispatchThreadMessageEx(pMsg))
   return TRUE;

// walk from target to main window
CWnd* pMainWnd = AfxGetMainWnd();
if (CWnd::WalkPreTranslateTree(pMainWnd->GetSafeHwnd(), pMsg))
   return TRUE;

// in case of modeless dialogs, last chance route through main
//   window's accelerator table
if (pMainWnd != NULL)
{
   CWnd* pWnd = CWnd::FromHandle(pMsg->hwnd);
   if (pWnd->GetTopLevelParent() != pMainWnd)
    return pMainWnd->PreTranslateMessage(pMsg);
}

return FALSE;   // no special processing
}

由上面这个函数可以看出：

第一，如果(pMsg->hwnd == NULL),说明这是一个线程消息。调用CWinThread::DispatchThreadMessageEx到消息映射表找到消息入口，然后调用消息处理函数。

NOTE: 一般用PostThreadMessage函数发送线程之间的消息，他和窗口消息不同，需要指定线程id,消息激被系统放入到目标线程的消息队列中；用 ON_THREAD_MESSAGE( message, memberFxn )宏可以映射线程消息和他的处理函数。这个宏必须在应用程序类(从CWinThread继承)中，因为只有应用程序类才处理线程消息。如果你在别的类(比 如视图类)中用这个宏，线程消息的消息处理函数将得不到线程消息。

第二，消息的目标窗口的 PreTranslateMessage函数首先得到消息处理权，如果函数返回FALSE，那么他的父窗口将得到消息的处理权，直到主窗口；如果函数返回 TRUE(表示消息已经被处理了)，那么就不需要调用父类的PreTranslateMessage函数。这样，保证了消息的目标窗口以及他的父窗口都可 以有机会调用PreTranslateMessage--在消息发送到窗口之前进行预处理(如果自己处理完然后返回FALSE的话 -_-b),如果你想要消息不传递给父类进行处理的话，返回TRUE就行了。

第三，如果消息的目标窗口和主窗口没有父子关系，那么再调用主 窗口的PreTranslateMessage函数。为什么这样？由第二步知道，一个窗口的父窗口不是主窗口的话，尽管它的 PreTranslateMessage返回FALSE，主窗口也没有机会调用PreTranslateMessage函数。我们知道，加速键的转换一般 在框架窗口的PreTranslateMessage函数中。我找遍了MFC中关于加速键转换的处理，只有CFrameWnd, CMDIFrameWnd，CMDIChildWnd等窗口类有。所以，第三步的意思是，如果消息的目标窗口(他的父窗口不是主窗口，比如一个这样的非模 式对话框)使消息的预处理继续漫游的话(他的PreTranslateMessage返回FALSE)，那么给一次机会给主窗口调用 PreTranslateMessage(万一他是某个加速键消息呢？)，这样能够保证在有非模式对话框的情况下还能保证主窗口的加速键好使。
我做了一个小例子，在对话框类的PreTranslateMessage中，返回FALSE。在主窗口显示这个非模式对话框，在对话框拥有焦点的时候，仍然能够激活主窗口的快捷键。

总之，整个框架就是让每个消息的目标窗口(包括他的父窗口)都有机会参与消息到来之前的处理。呵呵~

至 此，非对话框的消息循环和消息泵的机制就差不多了。这个机制在一个无限循环中，不断地从消息队列中获取消息，并且保证了程序的线程消息能够得到机会处理， 窗口消息在预处理之后被发送到相应的窗口处理过程。那么，还有一点疑问，为什么要一会儿调用::PeekMessage,一会儿调用:: GetMessage呢，他们有什么区别？

NOTE：一般来说，GetMessage被设计用来高效地从消息队列获取消息。如果队列中没有消息，那么函数GetMessage将导致线程休眠(让出CPU时间)。而PeekMessage是判断消息队列中如果没有消息，它马上返回0，不会导致线程处于睡眠状态。

在 上面的phase1第一个内循环中用到了PeekMessage，它的参数PM_NOREMOVE表示并不从消息队列中移走消息，而是一个检测查询，如果 消息队列中没有消息他立刻返回0，如果这时线程空闲的话将会引起消息循环调用OnIdle处理过程(上面讲到了这个函数的重要性)。如果将:: PeekMessage改成::GetMessage(***),那么如果消息队列中没有消息，线程将休眠，直到线程下一次获得CPU时间并且有消息出现 才可能继续执行，这样，消息循环的空闲时间没有得到应用，OnIdle也将得不到执行。这就是为什么既要用::PeekMessage(查询),又要 用::GetMessage(做实际的工作)的缘故。

第二部分: 对话框程序的消息循环机制

基于对话框的MFC工程和上面的消息循环机制不一样。实际上MFC的对话框工程程序就是模式对话框。他和上面讲到的非对话框程序的不同之处，主要在于应用程序对象的InitInstance()不一样。

//dlg_5Dlg.cpp
BOOL CDlg_5App::InitInstance()
{
AfxEnableControlContainer();
#ifdef _AFXDLL
Enable3dControls();    // Call this when using MFC in a shared DLL
#else
Enable3dControlsStatic(); // Call this when linking to MFC statically
#endif

CDlg_5Dlg dlg; //定义一个对话框对象
m_pMainWnd = &dlg;
int nResponse = dlg.DoModal(); //对话框的消息循环在这里面开始
if (nResponse == IDOK)
{
   // TODO: Place code here to handle when the dialog is
   // dismissed with OK
}
else if (nResponse == IDCANCEL)
{
   // TODO: Place code here to handle when the dialog is
   // dismissed with Cancel
}

// Since the dialog has been closed, return FALSE so that we exit the
// application, rather than start the application's message pump.
return FALSE;
}

NOTE: InitInstance函数返回FALSE，由最上面程序启动流程可以看出，CWinThread::Run是不会得到执行的。也就是说，上面第一部分 说的消息循环在对话框中是不能执行的。实际上，对话框也有消息循环，她的消息循环在CDialog::DoModal()虚函数中的一个 RunModalLoop函数中。

这个函数的实现体在CWnd类中：
int CWnd::RunModalLoop(DWORD dwFlags)
{
ASSERT(::IsWindow(m_hWnd)); // window must be created
ASSERT(!(m_nFlags & WF_MODALLOOP)); // window must not already be in modal state

// for tracking the idle time state
BOOL bIdle = TRUE;
LONG lIdleCount = 0;
BOOL bShowIdle = (dwFlags & MLF_SHOWONIDLE) && !(GetStyle() & WS_VISIBLE);
HWND hWndParent = ::GetParent(m_hWnd);
m_nFlags |= (WF_MODALLOOP|WF_CONTINUEMODAL);
MSG* pMsg = &AfxGetThread()->m_msgCur;

// acquire and dispatch messages until the modal state is done
for (;;)
{
   ASSERT(ContinueModal());

   // phase1: check to see if we can do idle work
   while (bIdle &&
    !::PeekMessage(pMsg, NULL, NULL, NULL, PM_NOREMOVE))
   {
    ASSERT(ContinueModal());

    // show the dialog when the message queue goes idle
    if (bShowIdle)
    {
     ShowWindow(SW_SHOWNORMAL);
     UpdateWindow();
     bShowIdle = FALSE;
    }

    // call OnIdle while in bIdle state
    if (!(dwFlags & MLF_NOIDLEMSG) && hWndParent != NULL && lIdleCount == 0)
    {
     // send WM_ENTERIDLE to the parent
     ::SendMessage(hWndParent, WM_ENTERIDLE, MSGF_DIALOGBOX, (LPARAM)m_hWnd);
    }
    if ((dwFlags & MLF_NOKICKIDLE) ||
     !SendMessage(WM_KICKIDLE, MSGF_DIALOGBOX, lIdleCount++))
    {
     // stop idle processing next time
     bIdle = FALSE;
    }
   }

// phase2: pump messages while available
   do
   {
    ASSERT(ContinueModal());

    // pump message, but quit on WM_QUIT
   //PumpMessage(消息泵)的实现和上面讲的差不多。都是派送消息到窗口。
    if (!AfxGetThread()->PumpMessage())
    {
     AfxPostQuitMessage(0);
     return -1;
    }

    // show the window when certain special messages rec'd
    if (bShowIdle &&
     (pMsg->message == 0x118 || pMsg->message == WM_SYSKEYDOWN))
    {
     ShowWindow(SW_SHOWNORMAL);
     UpdateWindow();
     bShowIdle = FALSE;
    }

    if (!ContinueModal())
     goto ExitModal;

    // reset "no idle" state after pumping "normal" message
    if (AfxGetThread()->IsIdleMessage(pMsg))
    {
     bIdle = TRUE;
     lIdleCount = 0;
    }

   } while (::PeekMessage(pMsg, NULL, NULL, NULL, PM_NOREMOVE));
} //无限循环

ExitModal:
m_nFlags &= ~(WF_MODALLOOP|WF_CONTINUEMODAL);
return m_nModalResult;
}

先说说怎么退出这个无限循环，在代码中：
if (!ContinueModal())
goto ExitModal;
决定是否退出循环，消息循环函数返回也就是快要结束结束程序了。
BOOL CWnd::ContinueModal()
{
return m_nFlags & WF_CONTINUEMODAL;
}

NOTE: CWnd::ContinueModal()函数检查对话框是否继续模式。返回TRUE,表示现在是模式的；返回FALSE，表示对话框已经不是模式(将要结束)。

如 果要结束对话框，在内部最终会调用函数CWnd::EndModalLoop，它取消m_nFlags的模式标志(消息循环中的 ContinueModal函数将返回FALSE，消息循环将结束，程序将退出)；然后激发消息循环读取消息。也就是说，结束模式对话框是一个标志，改变 这个标志就可以了。他的代码是：

//wincore.cpp
void CWnd::EndModalLoop(int nResult)
{
ASSERT(::IsWindow(m_hWnd));

// this result will be returned from CWnd::RunModalLoop
m_nModalResult = nResult;

// make sure a message goes through to exit the modal loop
if (m_nFlags & WF_CONTINUEMODAL)
{
   m_nFlags &= ~WF_CONTINUEMODAL;
   PostMessage(WM_NULL);
}
}

NOTE: PostMessage(NULL)是有用的。如果消息队列中没有消息的话，可能消息循环中的ContinueModal()不会马上执行，发送一个空消息是激发消息循环马上工作。

下面说一下CWnd::RunModalLoop函数中的消息循环究竟干了些什么事情:
1, 第一个内循环。首先从消息队列中查询消息，如果对话框空闲，而且消息队列中没有消息，他做三件事情，大家应到都能从字面上明白什么意思。最重要的是发送 WM_KICKIDLE消息。为什么呢？第一部分讲到了，非对话框程序用OnIdle来更新用户界面(UI)，比如工具栏，状态栏。那么，如果对话框中也 有工具栏和状态栏呢，在哪里更新(网上有很多这样的程序)？可以处理WM_KICKIDLE消息：

LRESULT CDlg_5Dlg::OnKickIdle(WPARAM w,LPARAM l)
{
     //调用CWnd::UpdateDialogControls更新用户界面
     UpdateDialogControls(this, TRUE);
     return 0;
}

NOTE: CWnd::UpdateDialog函数发送CN_UPDATE_COMMAND_UI消息给所有的用户界面对话框控件。

2, 第二个内循环。最重要的还是PumpMessage派送消息到目标窗口。其他的，像第二个if语句，0x118消息好像是WM_SYSTIMER消息(系 统用来通知光标跳动的一个消息)。也就是说，如果消息为WM_SYSTIMER或者WM_SYSKEYDOWN,并且空闲显示标志为真的话，就显示窗口并 通知窗口立刻重绘。

总之，对话框的消息循环机制和非对话框(比如SDI,MDI)还是类似 的，仅仅侧重点不同。模式对话框是模式显示，自然有他的特点。下面部分讨论一下模式对话框和非模式对话框的区别。因为模式对话框有自己的特殊消息循环；而 非模式对话框，共用程序的消息循环，和普通的窗口已经没有什么大的区别了。

第三部分：模式对话框和非模式对话框的区别

这个话题已经有很多人讨论，我说说我所理解的意思。
在MFC 框架中，一个对话框对象DoModal一下就能产生一个模式对话框，Create一下就能产生一个非模式对话框。实际上，无论是模式对话框还是非模式对话 框，在MFC内部都是调用::CreateDialogIndirect(***)函数来创建非模式对话框。只是模式对话框作了更多的工作，包括使父窗口 无效，然后进入自己的消息循环等等。::CreateDialogIndirect(***)函数最终调用CreateWindowEx函数通知系统创建 窗体并返回句柄，他内部没有实现自己的消息循环。
非模式对话框创建之后立即返回，并且和主程序共用一个消息循环。非模式对话框要等对话框结束之后才返回，自己有消息循环。比如下面的代码：
CMyDlg* pdlg = new CMyDlg;
pdlg ->Create(IDD_DIALOG1);
pdlg->ShowWindow(SW_SHOW);
MessageBox("abc");
非模式对话框和消息框MessageBox几乎是同时弹出来。而如果将Create改成DoModal，那么，只能弹出模式对话框，在关闭了对话框之后(模式对话框自己的消息循环结束)，消息框才弹出来。

NOTE： 可以在模式对话框中调用GetParent()->EnableWindow(true);这样，主窗口的菜单，工具栏又激活了，能用了。MFC使 用非模式对话框来模拟模式对话框，而在win32 SDK程序中，模式对话框激发他的父窗口Enable操作是没有效果的。

关于消息循环总结：

1， 我们站在一个什么高度看消息循环？消息循环其实没有什么深奥的道理。如果一个邮递员要不断在一个城市中送信，我们要求他做什么？要求他来回跑，但他一次只 能在一个地方出现。如果我们的应用程序只有一个线程的话，我们要他不断地为窗口传递消息，我们怎么做？在一个循环中不断的检测消息，并将他发送到适当的窗 口。窗口可以有很多个，但消息循环只有一个，而且每时每刻最多只有一个地方在执行代码。为什么？ 看第二点。

2，因为是单线程的(程序进程 启动的时候，只有而且有一个线程，我们称他为主线程),所以就像邮递员一样，每次只能在某一个地方干活。什么意思呢？举个例子，用:: DiapatchMessage派送消息，在窗口处理过程(WinProc,窗口函数)返回之前，他是阻塞的,不会立即返回，也就是消息循环此时不能再从 消息队列中读取消息，直到::DispatchMessage返回。如果你在窗口函数中执行一个死循环操作，就算你用PostQuitMessage函数 退出，程序也会down掉。
while(1)
{
    PostQuitMessage(0); //程序照样down.
}
所 以，当窗口函数处理没有返回的时候，消息循环是不会从消息队列中读取消息的。这也是为什么在模式对话框中要自己用无限循环来继续消息循环，因为这个无限循 环阻塞了原来的消息循环，所以，在这个无限循环中要用GetMessage,PeekMessage,DispatchMessage来从消息队列中读取 消息并派送消息了。要不然程序就不会响应了，这不是我们所希望的。
所以说，消息循环放在程序的什么的地方都基本上是过的去的，比如放在DLL里 面。但是，最好在任何时候，只有一个消息循环在工作(其他的都被阻塞了)。然后，我们要作好的一件事情，就是怎么从消息循环中退出！当然用WM_QUIT 是可以拉~(PostThreadMessage也是个好主意)，这个消息循环退出后，可能程序退出，也可能会激活另外一个被阻塞的消息循环，程序继续运 行。这要看你怎么想，怎么去做。最后一个消息循环结束的时候，也许就是程序快结束的时候，因为主线程的执行代码也快要完了(除非BT的再作个死循环)。

NOTE: 让windows系统知道创建一个线程的唯一方法是调用API CreatThread函数(__beginthreadex之类的都要在内部调用他创建新线程)。好像windows核心编程说，在win2000下， 系统用CreateRemoteThread函数来创建线程，CreateThread在内部调用CreateRemoteThread。不过这不是争论 的焦点，至少win98下CreateRemoteThread并不能正常工作，还是CreateThread主持大局。

3，在整个消息循环的机制中，还必须谈到窗口函数的可重入性。什么意思？就是窗口函数(他是个回调函数)的代码什么时候都可以被系统(调用者一般是user32模块)调用。比如在窗口过程中，向自己的窗口SendMessage(***);那么执行过程是怎样的？
我们知道，SendMessage是要等到消息发送并被目标窗口执行完之后才返回的。那么窗口在处理消息，然后又等待刚才发送到本窗口的消息被处理后之后(SendMessage返回)才继续往下执行，程序不就互相死锁了吗？
其 实是不会的。windows设计一套适合SendMessage的算法，他判断如果发送的消息是属于本线程创建的窗口的，那么直接由user32模块调用 窗口函数(可能就有窗口重入)，并将消息的处理结果结果返回。这样做体现了窗口重入。上面的例子，我们调用SendMessage(***)发送消息到本 窗口，那么窗口过程再次被调用，处理完消息之后将结果返回，然后SendMessage之后的程序接着执行。对于非队列消息，如果没有窗口重入，不知道会 是什么样子。

NOTE: 由于窗口的可重入性。在win32 SDK程序中应尽量少用全局变量和静态变量，因为在窗口函数执行过程中可能窗口重入，如果重入后将这些变量改了，但你的程序在窗口重入返回之后继续执行， 可能就是使用已经改变的全局或静态变量。在MFC中(所有窗口的窗口函数基本上都是AfxWndProc)，按照类的思想进行了组织，一般变量都是类中 的，好管理的多。

4,MFC中窗口类(比如C**View,CFrameWnd等)中的MessageBox函数，以及 AfxMessageBox函数都是阻塞原有的消息循环的。由消息框内部的一个消息循环来从消息队列中读取消息，并派送消息(和模式对话框类似)。实际 上，这些消息函数最终调用的是::MessageBox，它在消息框内部实现了一个消息循环(原有的主程序消息循环被阻塞了)。论坛中碰到过几次关于计时 器和消息框的问题，看下面的代码：
void CTest_recalclayoutView::OnTimer(UINT nIDEvent)
{
// TODO: Add your message handler code here and/or call default
MessageBox("abc");
while(1); //设计一个死循环
CView::OnTimer(nIDEvent);
}
咱 让OnTimer大约5秒钟弹出一个消息框。那么，消息框不断的被弹出来，只要消息框不被关闭，那么程序就不会进入死循环。实际上，每次弹出对话框，都是 最上层的那个消息框掌握着消息循环，其他的消息循环被阻塞了。只要不关闭最上面的消息框，while(1);就得不到执行。如果点了关闭，程序就进入了死 循环，只能用ctrl+alt+del来解决问题了。

5，消息循环在很多地方都有应用。比如应用在线程池中。一个线程的执行周期一般在线程 函数返回之后结束，那么怎么延长线程的生命周期呢？一种方法就是按照消息循环的思想，在线程中加入消息循环，不断地从线程队列读取消息，并处理消息，线程 的生命周期就保持着直到这个消息循环的退出。

NOTE：只要线程有界面元素或者调用GetMessage,或者有线程消息发送过来，系统就会为线程创建一个消息队列。

6, 在单线程程序中，如果要执行一个长时间的复杂操作而且界面要有相应的话，可以考虑用自己的消息泵。比如，可以将一个阻塞等待操作放在一个循环中，并将超时 值设置得比较小，然后每个等待的片段中用消息泵继续消息循环，使界面能够响应用户操作。等等之类，都可以应用消息泵(调用一个类似这样的函数)：
BOOL CChildView::PeekAndPump()
{
MSG msg;
while(::PeekMessage(&msg,NULL,0,0,PM_NOREMOVE))
{
   if(!AfxGetApp()->PumpMessage())
   {
    ::PostQuitMessage(0);
    return false;
   }
}
return true;
}
其实，用多线程也能解决复杂运算时的界面问题，但是没有这么方便，而且一般要加入线程通信和同步，考虑的事情更多一点。

综上所述，MFC消息循环就那么回事，主要思想还是和SDK中差不多。这种思想主要的特点表现在迎合MFC整个框架上，为整个框架服务，为应用和功能服务。这是我的理解。呵呵~