{

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整个框架上，为整个框架服务，为应用和功能服务。这是我的理解。呵呵~

ASCII table and description
ASCII stands for American Standard Code for Information Interchange. Computers can only understand numbers, so an ASCII code is the numerical representation of a character such as 'a' or '@' or an action of some sort. ASCII was developed a long time ago and now the non-printing characters are rarely used for their original purpose. Below is the ASCII character table and this includes descriptions of the first 32 non-printing characters. ASCII was actually designed for use with teletypes and so the descriptions are somewhat obscure. If someone says they want your CV however in ASCII format, all this means is they want 'plain' text with no formatting such as tabs, bold or underscoring - the raw format that any computer can understand. This is usually so they can easily import the file into their own applications without issues. Notepad.exe creates ASCII text, or in MS Word you can save a file as 'text only'

Extended ASCII Codes

.

.

 ----------------------------------------------------------------------------------------------------

ASCII Table (7-bit)
( ASCII = A merican S tandard C ode for I nformation I nterchange)
(also see Related Links below)

       Decimal   Octal   Hex    Binary     Value       postil
       -------   -----   ---    ------     -----      --------
         000      000    000   00000000      NUL    (Null char.)
         001      001    001   00000001      SOH    (Start of Header)
         002      002    002   00000010      STX    (Start of Text)
         003      003    003   00000011      ETX    (End of Text)
         004      004    004   00000100      EOT    (End of Transmission)
         005      005    005   00000101      ENQ    (Enquiry)
         006      006    006   00000110      ACK    (Acknowledgment)
         007      007    007   00000111      BEL    (Bell)
         008      010    008   00001000       BS    (Backspace)
         009      011    009   00001001       HT    (Horizontal Tab)
         010      012    00A   00001010       LF    (Line Feed)
         011      013    00B   00001011       VT    (Vertical Tab)
         012      014    00C   00001100       FF    (Form Feed)
         013      015    00D   00001101       CR    (Carriage Return)
         014      016    00E   00001110       SO    (Shift Out)
         015      017    00F   00001111       SI    (Shift In)
         016      020    010   00010000      DLE    (Data Link Escape)
         017      021    011   00010001      DC1 (XON) (Device Control 1)
         018      022    012   00010010      DC2       (Device Control 2)
         019      023    013   00010011      DC3 (XOFF)(Device Control 3)
         020      024    014   00010100      DC4       (Device Control 4)
         021      025    015   00010101      NAK    (Negative Acknowledgement)
         022      026    016   00010110      SYN    (Synchronous Idle)
         023      027    017   00010111      ETB    (End of Trans. Block)
         024      030    018   00011000      CAN    (Cancel)
         025      031    019   00011001       EM    (End of Medium)
         026      032    01A   00011010      SUB    (Substitute)
         027      033    01B   00011011      ESC    (Escape)
         028      034    01C   00011100       FS    (File Separator)
         029      035    01D   00011101       GS    (Group Separator)
         030      036    01E   00011110       RS    (Request to Send)(Record Separator)
         031      037    01F   00011111       US    (Unit Separator)
         032      040    020   00100000       SP    (Space)
         033      041    021   00100001        !    (exclamation mark)
         034      042    022   00100010        "    (double quote)
         035      043    023   00100011        #    (number sign)
         036      044    024   00100100        $    (dollar sign)
         037      045    025   00100101        %    (percent)
         038      046    026   00100110        &    (ampersand)
         039      047    027   00100111        '    (single quote)
         040      050    028   00101000        (    (left/opening parenthesis)
         041      051    029   00101001        )    (right/closing parenthesis)
         042      052    02A   00101010        *    (asterisk)
         043      053    02B   00101011        +    (plus)
         044      054    02C   00101100        ,    (comma)
         045      055    02D   00101101        -    (minus or dash)
         046      056    02E   00101110        .    (dot)
         047      057    02F   00101111        /    (forward slash)
         048      060    030   00110000        0
         049      061    031   00110001        1
         050      062    032   00110010        2
         051      063    033   00110011        3
         052      064    034   00110100        4
         053      065    035   00110101        5
         054      066    036   00110110        6
         055      067    037   00110111        7
         056      070    038   00111000        8
         057      071    039   00111001        9
         058      072    03A   00111010        :    (colon)
         059      073    03B   00111011        ;    (semi-colon)
         060      074    03C   00111100        <    (less than)
         061      075    03D   00111101        =    (equal sign)
         062      076    03E   00111110        >    (greater than)
         063      077    03F   00111111        ?    (question mark)
         064      100    040   01000000        @    (AT symbol)
         065      101    041   01000001        A
         066      102    042   01000010        B
         067      103    043   01000011        C
         068      104    044   01000100        D
         069      105    045   01000101        E
         070      106    046   01000110        F
         071      107    047   01000111        G
         072      110    048   01001000        H
         073      111    049   01001001        I
         074      112    04A   01001010        J
         075      113    04B   01001011        K
         076      114    04C   01001100        L
         077      115    04D   01001101        M
         078      116    04E   01001110        N
         079      117    04F   01001111        O
         080      120    050   01010000        P
         081      121    051   01010001        Q
         082      122    052   01010010        R
         083      123    053   01010011        S
         084      124    054   01010100        T
         085      125    055   01010101        U
         086      126    056   01010110        V
         087      127    057   01010111        W
         088      130    058   01011000        X
         089      131    059   01011001        Y
         090      132    05A   01011010        Z
         091      133    05B   01011011        [    (left/opening bracket)
         092      134    05C   01011100        \    (back slash)
         093      135    05D   01011101        ]    (right/closing bracket)
         094      136    05E   01011110        ^    (caret/cirumflex)
         095      137    05F   01011111        _    (underscore)
         096      140    060   01100000        `
         097      141    061   01100001        a
         098      142    062   01100010        b
         099      143    063   01100011        c
         100      144    064   01100100        d
         101      145    065   01100101        e
         102      146    066   01100110        f
         103      147    067   01100111        g
         104      150    068   01101000        h
         105      151    069   01101001        i
         106      152    06A   01101010        j
         107      153    06B   01101011        k
         108      154    06C   01101100        l
         109      155    06D   01101101        m

         110      156    06E   01101110        n
         111      157    06F   01101111        o
         112      160    070   01110000        p
         113      161    071   01110001        q
         114      162    072   01110010        r
         115      163    073   01110011        s
         116      164    074   01110100        t

         117      165    075   01110101        u
         118      166    076   01110110        v

         119      167    077   01110111        w
         120      170    078   01111000        x
         121      171    079   01111001        y
         122      172    07A   01111010        z
         123      173    07B   01111011        {    (left/opening brace)
         124      174    07C   01111100        |    (vertical bar)
         125      175    07D   01111101        }    (right/closing brace)
         126      176    07E   01111110        ~    (tilde)
         127      177    07F   01111111      DEL    (delete)

友元函数和友元类


        采用类的机制后实现了数据的隐藏与封装，类的数据成员一般定义为私有成员，成员函数一般定义为公有的，依此提供类与外界间的通信接口。但是，有时需要定义一些函数，这些函数不是类的一部分，但又需要频繁地访问类的数据成员，这时可以将这些函数定义为该函数的友元函数。除了友元函数外，还有友元类，两者统称为友元。友元的作用是提高了程序的运行效率（即减少了类型检查和安全性检查等都需要时间开销），但它破坏了类的封装性和隐藏性，使得非成员函数可以访问类的私有成员。

友元函数 ：
      友元函数是可以直接访问类的私有成员的非成员函数。它是定义在类外的普通函数，它不属于任何类，但需要在类的定义中加以声明，声明时只需在友元的名称前加上关键字friend，其格式如下：
      friend  类型 函数名(形式参数);

      友元函数的声明可以放在类的私有部分，也可以放在公有部分，它们是没有区别的，都说明是该类的一个友元函数。
      一个函数可以是多个类的友元函数，只需要在各个类中分别声明。
      友元函数的调用与一般函数的调用方式和原理一致。

友元类 ：
      友元类的所有成员函数都是另一个类的友元函数，都可以访问另一个类中的隐藏信息（包括私有成员和保护成员）。       
      当希望一个类可以存取另一个类的私有成员时，可以将该类声明为另一类的友元类。定义友元类的语句格式如下：
      friend class 类名;
      其中：friend和class是关键字，类名必须是程序中的一个已定义过的类。

      例如，以下语句说明类B是类A的友元类：
      class A
      {
             …
      public:
             friend class B;
             …
      };
      经过以上说明后，类B的所有成员函数都是类A的友元函数，能存取类A的私有成员和保护成员。

      使用友元类时注意：
            (1) 友元关系不能被继承。
            (2) 友元关系是单向的，不具有交换性。若类B是类A的友元，类A不一定是类B的友元，要看在类中是否有相应的声明。
            (3) 友元关系不具有传递性。若类B是类A的友元，类C是B的友元，类C不一定是类A的友元，同样要看类中是否有相应的申明

VC编程经验汇总

(1)message 参数

    message参数是我最喜欢的一个参数，它能够在编译信息输出窗口中输出相应的信息，
这对于源代码信息的控制是非常重要的。其使用方法为： 
    #pragma  message("消息文本") 
    当编译器遇到这条指令时就在编译输出窗口中将消息文本打印出来。 
    当我们在程序中定义了许多宏来控制源代码版本的时候，我们自己有可能都会忘记有没有正确的设置这些宏，
此时我们可以用这条指令在编译的时候就进行检查。假设我们希望判断自己有没有在源代码的什么地方定义了_X86这个宏,
可以用下面的方法:
    #ifdef  _X86 
    #pragma  message("_X86  macro  activated!") 
    #endif 
    我们定义了_X86这个宏以后，应用程序在编译时就会在编译输出窗口里显示"_86  macro  activated!"。
我们就不会因为不记得自己定义的一些特定的宏而抓耳挠腮了。 
      

(2)另一个使用得比较多的pragma参数是code_seg

    格式如： 
    #pragma  code_seg( ["section-name" [, "section-class"] ] ) 
    它能够设置程序中函数代码存放的代码段，当我们开发驱动程序的时候就会使用到它。 
 

(3)#pragma once  (比较常用) 

    只要在头文件的最开始加入这条指令就能够保证头文件被编译一次，这条指令实际上在VC6中就已经有了，
但是考虑到兼容性并没有太多的使用它。 

      
(4)#pragma  hdrstop

    表示预编译头文件到此为止，后面的头文件不进行预编译。BCB可以预编译头文件以加快链接的速度，
但如果所有头文件都进行预编译又可能占太多磁盘空间，所以使用这个选项排除一些头文件。   
    有时单元之间有依赖关系，比如单元A依赖单元B，所以单元B要先于单元A编译。
你可以用#pragma  startup指定编译优先级，如果使用了#pragma  package(smart_init)，
BCB就会根据优先级的大小先后编译。   

      
(5)#pragma  resource  "*.dfm"

    表示把*.dfm文件中的资源加入工程。*.dfm中包括窗体 
外观的定义。   

        
(6)#pragma  warning( disable: 4507 34; once: 4385; error: 164 )
 
    等价于： 
    #pragma  warning( disable: 4507 34 )    //  不显示4507和34号警告信息 
    #pragma  warning( once: 4385 )          //  4385号警告信息仅报告一次 
    #pragma  warning( error: 164 )          //  把164号警告信息作为一个错误。 

    同时这个pragma  warning  也支持如下格式： 
    #pragma  warning( push [, n ] ) 
    #pragma  warning( pop ) 
    这里n代表一个警告等级(1---4)。 
    #pragma  warning( push )保存所有警告信息的现有的警告状态。 
    #pragma  warning( push, n )保存所有警告信息的现有的警告状态，并且把全局警告等级设定为n。   
    #pragma  warning( pop )向栈中弹出最后一个警告信息，在入栈和出栈之间所作的一切改动取消。例如： 
    #pragma  warning( push ) 
    #pragma  warning( disable: 4705 ) 
    #pragma  warning( disable: 4706 ) 
    #pragma  warning( disable: 4707 ) 
    //....... 
    #pragma  warning(  pop  )   
    在这段代码的最后，重新保存所有的警告信息(包括4705，4706和4707)。 

(7)#pragma  comment(...) 

    该指令将一个注释记录放入一个对象文件或可执行文件中。 
常用的lib关键字，可以帮我们连入一个库文件。如：
    #pragma  comment(lib, "comctl32.lib")
    #pragma  comment(lib, "vfw32.lib")
    #pragma  comment(lib, "wsock32.lib")
 
  
  
每个编译程序可以用#pragma指令激活或终止该编译程序支持的一些编译功能。

例如，对循环优化功能： 
#pragma  loop_opt(on)     //  激活 
#pragma  loop_opt(off)    //  终止 

有时，程序中会有些函数会使编译器发出你熟知而想忽略的警告，
如“Parameter  xxx  is  never  used  in  function  xxx”，可以这样： 
#pragma  warn  —100         //  Turn  off  the  warning  message  for  warning  #100 
int  insert_record(REC  *r) 
{  /*  function  body  */  } 
#pragma  warn  +100          //  Turn  the  warning  message  for  warning  #100  back  on 
函数会产生一条有唯一特征码100的警告信息，如此可暂时终止该警告。 

每个编译器对#pragma的实现不同，在一个编译器中有效在别的编译器中几乎无效。可从编译器的文档中查看。

补充 —— #pragma pack 与 内存对齐问题

    许多实际的计算机系统对基本类型数据在内存中存放的位置有限制，它们会要求这些数据的首地址的值是某个数k
(通常它为4或8)的倍数，这就是所谓的内存对齐，而这个k则被称为该数据类型的对齐模数(alignment modulus)。

    Win32平台下的微软C编译器(cl.exe for 80x86)在默认情况下采用如下的对齐规则:
    任何基本数据类型T的对齐模数就是T的大小，即sizeof(T)。比如对于double类型(8字节)，
就要求该类型数据的地址总是8的倍数，而char类型数据(1字节)则可以从任何一个地址开始。

    Linux下的GCC奉行的是另外一套规则(在资料中查得，并未验证，如错误请指正):
    任何2字节大小(包括单字节吗?)的数据类型(比如short)的对齐模数是2，而其它所有超过2字节的数据类型
(比如long,double)都以4为对齐模数。

    ANSI C规定一种结构类型的大小是它所有字段的大小以及字段之间或字段尾部的填充区大小之和。
填充区就是为了使结构体字段满足内存对齐要求而额外分配给结构体的空间。那么结构体本身有什么对齐要求吗？
有的，ANSI C标准规定结构体类型的对齐要求不能比它所有字段中要求最严格的那个宽松，可以更严格。

如何使用c/c++中的对齐选项

    vc6中的编译选项有 /Zp[1|2|4|8|16] ，/Zp1表示以1字节边界对齐，相应的，/Zpn表示以n字节边界对齐。
n字节边界对齐的意思是说，一个成员的地址必须安排在成员的尺寸的整数倍地址上或者是n的整数倍地址上，取它们中的最小值。
也就是：
    min ( sizeof ( member ),  n)

    实际上，1字节边界对齐也就表示了结构成员之间没有空洞。
    /Zpn选项是应用于整个工程的，影响所有的参与编译的结构。
    要使用这个选项，可以在vc6中打开工程属性页，c/c++页，选择Code Generation分类，在Struct member alignment可以选择。

    要专门针对某些结构定义使用对齐选项，可以使用#pragma pack编译指令:

(1) #pragma  pack( [ n ] )

    该指令指定结构和联合成员的紧凑对齐。而一个完整的转换单元的结构和联合的紧凑对齐由/Zp 选项设置。
紧凑对齐用pack编译指示在数据说明层设置。该编译指示在其出现后的第一个结构或联合说明处生效。
该编译指示对定义无效。
    当你使用#pragma  pack ( n ) 时, 这里n 为1、2、4、8 或16。
    第一个结构成员之后的每个结构成员都被存储在更小的成员类型或n 字节界限内。
如果你使用无参量的#pragma  pack, 结构成员被紧凑为以/Zp 指定的值。该缺省/Zp 紧凑值为/Zp8 。

(2) 编译器也支持以下增强型语法:
    #pragma  pack( [ [ { push | pop } , ] [ identifier, ] ] [ n] )

    若不同的组件使用pack编译指示指定不同的紧凑对齐, 这个语法允许你把程序组件组合为一个单独的转换单元。
带push参量的pack编译指示的每次出现将当前的紧凑对齐存储到一个内部编译器堆栈中。
    编译指示的参量表从左到右读取。如果你使用push, 则当前紧凑值被存储起来;
如果你给出一个n 的值, 该值将成为新的紧凑值。若你指定一个标识符, 即你选定一个名称,
则该标识符将和这个新的的紧凑值联系起来。

    带一个pop参量的pack编译指示的每次出现都会检索内部编译器堆栈顶的值,并且使该值为新的紧凑对齐值。
如果你使用pop参量且内部编译器堆栈是空的,则紧凑值为命令行给定的值, 并且将产生一个警告信息。
若你使用pop且指定一个n的值, 该值将成为新的紧凑值。若你使用p o p 且指定一个标识符,
所有存储在堆栈中的值将从栈中删除, 直到找到一个匹配的标识符, 这个与标识符相关的紧凑值也从栈中移出,
并且这个仅在标识符入栈之前存在的紧凑值成为新的紧凑值。如果未找到匹配的标识符,
将使用命令行设置的紧凑值, 并且将产生一个一级警告。缺省紧凑对齐为8 。

   pack编译指示的新的增强功能让你编写头文件, 确保在遇到该头文件的前后的
紧凑值是一样的。

(3) 栈内存对齐

    在vc6中栈的对齐方式不受结构成员对齐选项的影响。它总是保持对齐，而且对齐在4字节边界上。