在计算机程序或文本编辑中，hardcode(这个词比hard code用起来要频繁一些)是指将可变变量用一个固定值来代替的方法。用这种方法编译后，如果以后需要更改此变量就非常困难了。大部分程序语言里，可以将一个固定数值定义为一个标记，然后用这个特殊标记来取代变量名称。当标记名称改变时，变量名不变，这样，当重新编译整个程序时，所有变量都不再是固定值，这样就更容易的实现了改变变量的目的。尽管通过编辑器的查找替换功能也能实现整个变量名称的替换，但也很有可能出现多换或者少换的情况，而在计算机程序中，任何小错误的出现都是不可饶恕的。最好的方法是单独为变量名划分空间，来实现这种变化，就如同前面说的那样，将需要改变的变量名暂时用一个定义好的标记名称来代替就是一种很好的方法。通常情况下，都应该避免使用hardcode方法。　　

有时也用hardcode来形容那些非常难学的语言，比如C或者C++语言，相对的，用softcode来形容象VB这类简单好用的程序语言。

很好理解,windows操作系统使用消息处理机制,那么,我们所设计的程序如何才能分辨和处理系统中的各种消息呢?这就是消息分流器的作用.

简单来说,消息分流器就是一段代码,在我的讲述中,将分7重来循序渐进的介绍它.从最初的第1重到最成熟的第7重,它的样子会有很大的变化.但,实现的功能都是一样的,所不同的,仅仅是变得更加简练罢了.

程序开始时候,会是main函数,然后会生成初始的窗口,同时会调用WndProc函数.这是一个自定义的函数,名字也会有变化,但其功能是一样的,就是运行消息分流器.WndProc函数如下:

LRESULT CALLBACK WndProc (HWND hwnd, UINT msg,WPARAM wParam, LPARAM lParam)
{

//......

return DefWindowProc(hwnd, msg, wParam, lParam);

}

这其中,hwnd是窗口的句柄,msg是系统发送来的消息的名字.wParam和lParam则是随消息一起发送来的消息参数.

WndProc函数使用了消息分流器，下面把消息分流器的内容解释一下：

一重，当不同的消息出现时，在其中写入相应的程序语句即可。
LRESULT CALLBACK WndProc (HWND hwnd, UINT msg,WPARAM wParam, LPARAM lParam)
{
 switch(msg)
 {
  case WM_CREATE:
  // ...
  return 0;

  case WM_PAINT:
  // ...
  return 0;

  case WM_DESTROY:
  //...
  return 0;
 }
 return DefWindowProc(hwnd, msg, wParam, lParam);
}

二重，运用三个消息分流器进行处理。
LRESULT CALLBACK WndProc (HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
 switch(msg)
 {
  case WM_CREATE:
  return HANDLE_WM_CREATE(hwnd, wParam, lParam, Cls_OnCreate);

  case WM_PAINT:
  return HANDLE_WM_PAINT(hwnd, wParam, lParam, Cls_OnPaint);

  case WM_DESTROY:
  return HANDLE_WM_DESTROY(hwnd, wParam, lParam, Cls_OnDestroy);
 }
 return DefWindowProc(hwnd, msg, wParam, lParam);
}
这里的HANDLE_WM_CREATE，HANDLE_WM_PAINT，HANDLE_WM_DESTROY就是消息分流器。
与消息不同之处就是在前面增加了“HANDLE_”字符，windows的消息分流器就是这样的模样。
它的本质就是宏定义。
其中的四个参数有三个都是从本函数的入口参数中直接得到的，即为hwnd, wParam, lParam。
只有第四的参数是表明调用的函数。
消息分流器是在winowsx.h文件中定义的。由此，可以看出第四个参数是调用的函数，其定义如下：

#define HANDLE_WM_CREATE(hwnd, wParam, lParam, fn) ((fn)((hwnd), (LPCREATESTRUCT)(lParam)) ? 0L : (LRESULT)-1L)

#define HANDLE_WM_PAINT(hwnd, wParam, lParam, fn) ((fn)(hwnd), 0L)

#define HANDLE_WM_DESTROYCLIPBOARD(hwnd, wParam, lParam, fn) ((fn)(hwnd), 0L)

0L是表示int类型的变量，其数值为0。
int类型时，可在后面加l或者L(小写和大写形式)
表明无符号数时，可在后面加u或者U(小写和大写形式)
float类型时，可在后面加f或者F(小写和大写形式)
例如：
128u 1024UL 1L 8Lu 3.14159F 0.1f

LRESULT是一个系统的数据类型，其定义如下：
typedef LONG_PTR LRESULT;

LONG_PTR也是一个系统的数据类型，其定义如下：
#if defined(_WIN64)
 typedef __int64 LONG_PTR;
#else
 typedef long LONG_PTR;
#endif
由此可见，LRESULT的实质就是64的long类型的变量

那么(LRESULT)-1L的实质并不是减法，而是((LRESULT)(-1L))，即强制类型转换

三重，把消息分流器的宏定义代换回去，就成了下面的样子
LRESULT CALLBACK WndProc (HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
 switch(msg)
 {
  case WM_CREATE:
  return Cls_OnCreate(hwnd, (LPCREATESTRUCT)(lParam)) ? 0L : (LRESULT)-1L;
  // 如果处理了消息，则Cls_OnCreate应返回TRUE，导致WndProc返回0，否则Cls_OnCreate返回FALSE，导致WndProc返回-1；

  case WM_PAINT:
  return Cls_OnPaint(hwnd), 0L;
  // 逗号表达式；Cls_OnPaint是void类型，这里返回0；

  case WM_DESTROY:
  return Cls_OnDestroy(hwnd), 0L; // 同Cls_OnPaint
 }
 return DefWindowProc(hwnd, msg, wParam, lParam);
}
在逗号表达式，C++会计算每个表达式，但完整的逗号表达式的结果是最右边表达式的值。
所以，会return 0。
然后，就可以手动的编写各个处理函数了：Cls_OnCreate，Cls_OnPaint，WM_DESTROY。

四重，
LRESULT CALLBACK WndProc (HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
 switch(msg)
 {
  HANDLE_MSG(hwnd, WM_CREATE, Cls_OnCreate);
  HANDLE_MSG(hwnd, WM_PAINT, Cls_OnPaint);
  HANDLE_MSG(hwnd, WM_DESTROY, Cls_OnDestroy);
 }
 return DefWindowProc(hwnd, msg, wParam, lParam);
}

HANDLE_MSG也是一个宏，它在windowsx.h中定义，如下：
#define HANDLE_MSG(hwnd, message, fn) case (message): return HANDLE_##message((hwnd), (wParam), (lParam), (fn))

这个宏要做的就是根据不同的message（##用来连接前后的字符串），把自己“变成”相应的HANDLE_XXXXMESSAGE形式的宏，再通过相应的宏来执行消息处理代码。
说白了，就是把message的消息做为替换，##就是一个替换的标志。
如果没有##，就成了HANDLE_message了，这样，宏是不会被代换的。
如果就单独一个，则会代换，如hwnd和fn。

比如实际代码中写入：
HANDLE_MSG(hwnd, WM_CREATE, Cls_OnCreate)
则经过转换就变成：
case (WM_CREATE): return HANDLE_WM_CREATE((hwnd), (wParam), (lParam), (Cls_OnCreate))
这与二重一模一样。

以上四重，是消息分离器的基本使用，但，这不完整，消息分离器主要应用在对话框消息处理中。
这里，窗口子类化是我们经常使用的手段，这也可以通过消息分流器实现，

第五重
LRESULT CALLBACK Dlg_Proc (HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
 switch(msg)
 {
  HANDLE_MSG(hwnd, WM_INITDIALO , Cls_OnInitDialog); // 不能直接使用HANDLE_MSG宏
  HANDLE_MSG(hwnd, WM_COMMAND, Cls_OnCommand); // 不能直接使用HANDLE_MSG宏
 }
 return false;
}
由于是窗口子类化，所以，最后，返回的是false，以表明，如果没有约定响应的消息，
则返回父亲窗口false，如果有，则返回ture，这是与前四重不同的地方。
一般情况下，对话框过程函数应该在处理了消息的情况下返回TRUE，如果没有处理，则返回FALSE。
如果对话框过程返回了FALSE，那么对话框管理器为这条消息准备默认的对话操作。

但是，这其中有错误，因为有的消息,需要单独处理。单独处理的消息列表见SetDlgMsgResult宏。

第六重
这点小问题，这就需要用到SetDlgMsgResult(hwnd, msg, result)宏。

LRESULT CALLBACK Dlg_Proc (HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
switch(msg)
 {
 case WM_INITDIALO:
 return (SetDlgMsgResult(hwnd, Msg, HANDLE_WM_INITDIALO((hwnd), (wParam), (lParam), (fn)));

 case WM_COMMAND:
 return (SetDlgMsgResult(hwnd, Msg, HANDLE_WM_COMMAND((hwnd), (wParam), (lParam), (fn)));
 }
return false;
}
这里，就用直接用到了第二重的消息分流器，而抛弃了其他。

这个宏定义如下：
#define SetDlgMsgResult(hwnd, msg, result)
(
 (
 (msg) == WM_CTLCOLORMSGBOX ||
 (msg) == WM_CTLCOLOREDIT ||
 (msg) == WM_CTLCOLORLISTBOX ||
 (msg) == WM_CTLCOLORBTN ||
 (msg) == WM_CTLCOLORDLG ||
 (msg) == WM_CTLCOLORSCROLLBAR ||
 (msg) == WM_CTLCOLORSTATIC ||
 (msg) == WM_COMPAREITEM ||
 (msg) == WM_VKEYTOITEM ||
 (msg) == WM_CHARTOITEM ||
 (msg) == WM_QUERYDRAGICON ||
 (msg) == WM_INITDIALOG
 ) ?
 (BOOL)(result) :
 (SetWindowLongPtr((hwnd), DWLP_MSGRESULT, (LPARAM)(LRESULT)(result)), TRUE)
)

为了表述清楚，所以用了此格式，这是一个三项表达式，首先对消息类型进行考察。

如果对话框过程处理的消息恰巧为返回特定值中的一个，则如实返回result；
不要被前面的BOOL蒙蔽，BOOL在头文件中的定义实际上是一个int型，
一旦需要返回非TRUE或FALSE的其他值，照样可以；

这样，我们的Cls_OnInitDialog就能够正确的返回它的BOOL值了，
而Cls_OnCommand在处理之后，也可以由后面的逗号表达式正确的返回一个TRUE表示消息已处理。

第七重
我们还可以把case也包含进来，就成了如下的样子。

LRESULT CALLBACK Dlg_Proc (HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
 switch(msg)
 {
 chHANDLE_DLGMSG(hwnd, WM_INITDIALOG, Cls_OnInitDialog);
 chHANDLE_DLGMSG(hwnd, WM_COMMAND, Cls_OnCommand);
 }
 return false;
}

chHANDLE_DLGMSG是牛人定义的一个宏，它把case也包含进来了。
#define chHANDLE_DLGMSG(hwnd, message, fn) case (message): return (SetDlgMsgResult(hwnd, uMsg, HANDLE_##message((hwnd), (wParam), (lParam), (fn))))

这样，程序中的语句
 switch (uMsg)
 {
  chHANDLE_DLGMSG(hwnd, WM_INITDIALOG, Dlg_OnInitDialog);
  chHANDLE_DLGMSG(hwnd, WM_SIZE,       Dlg_OnSize);
  chHANDLE_DLGMSG(hwnd, WM_COMMAND,    Dlg_OnCommand);
 }

就被翻译成：
 switch (uMsg)
 {
 case (WM_INITDIALOG):
  return (SetDlgMsgResult(hwnd, uMsg, HANDLE_WM_INITDIALOG((hwnd), (wParam), (lParam), (Dlg_OnInitDialog))));

 case (WM_SIZE)
  return (SetDlgMsgResult(hwnd, uMsg, HANDLE_WM_SIZE((hwnd), (wParam), (lParam), (Dlg_OnSize))));

 case (WM_COMMAND)
  return (SetDlgMsgResult(hwnd, uMsg, HANDLE_WM_COMMAND((hwnd), (wParam), (lParam), (Dlg_OnCommand))));
 }

这样,消息分流器,就介绍完毕.

1、插入器(<<)
　　向流输出数据。比如说系统有一个默认的标准输出流(cout)，一般情况下就是指的显示器，所以，cout<<"Write Stdout"<<' ';就表示把字符串"Write Stdout"和换行字符(' ')输出到标准输出流。

2、析取器(>>)
　　从流中输入数据。比如说系统有一个默认的标准输入流(cin)，一般情况下就是指的键盘，所以，cin>>x;就表示从标准输入流中读取一个指定类型(即变量x的类型)的数据。

　　在C++中，对文件的操作是通过stream的子类fstream(file stream)来实现的，所以，要用这种方式操作文件，就必须加入头文件fstream.h。下面就把此类的文件操作过程一一道来。

一、打开文件
　　在fstream类中，有一个成员函数open()，就是用来打开文件的，其原型是：

void open(const char* filename,int mode,int access);

参数：

filename：　　要打开的文件名
mode：　　　　要打开文件的方式
access：　　　打开文件的属性
打开文件的方式在类ios(是所有流式I/O类的基类)中定义，常用的值如下：

ios::app：　　　以追加的方式打开文件
ios::ate：　　　文件打开后定位到文件尾，ios:app就包含有此属性
ios::binary： 　以二进制方式打开文件，缺省的方式是文本方式。两种方式的区别见前文
ios::in：　　　 文件以输入方式打开
ios::out：　　　文件以输出方式打开
ios::nocreate： 不建立文件，所以文件不存在时打开失败　
ios::noreplace：不覆盖文件，所以打开文件时如果文件存在失败
ios::trunc：　　如果文件存在，把文件长度设为0
　　可以用“或”把以上属性连接起来，如ios::out|ios::binary

　　打开文件的属性取值是：

0：普通文件，打开访问
1：只读文件
2：隐含文件
4：系统文件
　　可以用“或”或者“+”把以上属性连接起来 ，如3或1|2就是以只读和隐含属性打开文件。

　　例如：以二进制输入方式打开文件c:config.sys

　　fstream file1;
　　file1.open("c:\config.sys",ios::binary|ios::in,0);

　　如果open函数只有文件名一个参数，则是以读/写普通文件打开，即：

　　file1.open("c:\config.sys");<=>file1.open("c:\config.sys",ios::in|ios::out,0);

　　另外，fstream还有和open()一样的构造函数，对于上例，在定义的时侯就可以打开文件了：

　　fstream file1("c:\config.sys");

　　特别提出的是，fstream有两个子类：ifstream(input file stream)和ofstream(outpu file stream)，ifstream默认以输入方式打开文件，而ofstream默认以输出方式打开文件。

　　ifstream file2("c:\pdos.def");//以输入方式打开文件
　　ofstream file3("c:\x.123");//以输出方式打开文件

　　所以，在实际应用中，根据需要的不同，选择不同的类来定义：如果想以输入方式打开，就用ifstream来定义；如果想以输出方式打开，就用ofstream来定义；如果想以输入/输出方式来打开，就用fstream来定义。

二、关闭文件
　　打开的文件使用完成后一定要关闭，fstream提供了成员函数close()来完成此操作，如：file1.close();就把file1相连的文件关闭。

三、读写文件
　　读写文件分为文本文件和二进制文件的读取，对于文本文件的读取比较简单，用插入器和析取器就可以了；而对于二进制的读取就要复杂些，下要就详细的介绍这两种方式

　　1、文本文件的读写
　　文本文件的读写很简单：用插入器(<<)向文件输出；用析取器(>>)从文件输入。假设file1是以输入方式打开，file2以输出打开。示例如下：

　　file2<<"I Love You";//向文件写入字符串"I Love You"
　　int i;
　　file1>>i;//从文件输入一个整数值。

　　这种方式还有一种简单的格式化能力，比如可以指定输出为16进制等等，具体的格式有以下一些

操纵符 功能 输入/输出
dec 格式化为十进制数值数据 输入和输出
endl 输出一个换行符并刷新此流 输出
ends 输出一个空字符 输出
hex 格式化为十六进制数值数据 输入和输出
oct 格式化为八进制数值数据 输入和输出
setpxecision(int p) 设置浮点数的精度位数 输出

　　比如要把123当作十六进制输出：file1<

　　2、二进制文件的读写
①put()
　　put()函数向流写入一个字符，其原型是ofstream &put(char ch)，使用也比较简单，如file1.put('c');就是向流写一个字符'c'。

②get()
　　get()函数比较灵活，有3种常用的重载形式：

　　一种就是和put()对应的形式：ifstream &get(char &ch);功能是从流中读取一个字符，结果保存在引用ch中，如果到文件尾，返回空字符。如file2.get(x);表示从文件中读取一个字符，并把读取的字符保存在x中。

　　另一种重载形式的原型是： int get();这种形式是从流中返回一个字符，如果到达文件尾，返回EOF，如x=file2.get();和上例功能是一样的。

　　还有一种形式的原型是：ifstream &get(char *buf,int num,char delim=' ')；这种形式把字符读入由 buf 指向的数组，直到读入了 num 个字符或遇到了由 delim 指定的字符，如果没使用 delim 这个参数，将使用缺省值换行符' '。例如：

　　file2.get(str1,127,'A');//从文件中读取字符到字符串str1，当遇到字符'A'或读取了127个字符时终止。

③读写数据块
　　要读写二进制数据块，使用成员函数read()和write()成员函数，它们原型如下：

　　　　read(unsigned char *buf,int num);
　　　　write(const unsigned char *buf,int num);

　　read()从文件中读取 num 个字符到 buf 指向的缓存中，如果在还未读入 num 个字符时就到了文件尾，可以用成员函数 int gcount();来取得实际读取的字符数；而 write() 从buf 指向的缓存写 num 个字符到文件中，值得注意的是缓存的类型是 unsigned char *，有时可能需要类型转换。

例：

　　　　unsigned char str1[]="I Love You";
　　　　int n[5];
　　　　ifstream in("xxx.xxx");
　　　　ofstream out("yyy.yyy");
　　　　out.write(str1,strlen(str1));//把字符串str1全部写到yyy.yyy中
　　　　in.read((unsigned char*)n,sizeof(n));//从xxx.xxx中读取指定个整数，注意类型转换
　　　　in.close();out.close();

四、检测EOF
　　成员函数eof()用来检测是否到达文件尾，如果到达文件尾返回非0值，否则返回0。原型是int eof();

例：　　if(in.eof())ShowMessage("已经到达文件尾！");

五、文件定位
　　和C的文件操作方式不同的是，C++ I/O系统管理两个与一个文件相联系的指针。一个是读指针，它说明输入操作在文件中的位置；另一个是写指针，它下次写操作的位置。每次执行输入或输出时，相应的指针自动变化。所以，C++的文件定位分为读位置和写位置的定位，对应的成员函数是 seekg()和 seekp()，seekg()是设置读位置，seekp是设置写位置。它们最通用的形式如下：

　　　　istream &seekg(streamoff offset,seek_dir origin);
　　　　ostream &seekp(streamoff offset,seek_dir origin);

　　streamoff定义于 iostream.h 中，定义有偏移量 offset 所能取得的最大值，seek_dir 表示移动的基准位置，是一个有以下值的枚举：

ios::beg：　　文件开头
ios::cur：　　文件当前位置
ios::end：　　文件结尾
　　这两个函数一般用于二进制文件，因为文本文件会因为系统对字符的解释而可能与预想的值不同。

例：

　　　　 file1.seekg(1234,ios::cur);//把文件的读指针从当前位置向后移1234个字节
　　　　 file2.seekp(1234,ios::beg);//把文件的写指针从文件开头向后移1234个字节

80x87的指令系统
浮点处理单元FPU具有自己的指令系统，共有几十种浮点指令，可以分成传送、算术运算、超越函数、比较、FPU控制等类。浮点指令归属于ESC指令，其前5位的操作码都是11011b，它的指令助记符均以F开头。
1. 浮点传送类指令
    浮点数据传送指令完成主存与栈顶st(0)、数据寄存器st(i)与栈顶之间的浮点格式数据的传送。浮点数据寄存器是一个首尾相接的堆栈，所以它的数据传送实际上是对堆栈的操作，有些要改变堆栈指针TOP，即修改当前栈顶。
2. 算术运算类指令
    这类浮点指令实现浮点数、16/32位整数的加、减、乘、除运算，它们支持的寻址方式相同。这组指令还包括有关算术运算的指令，例如求绝对值、取整等。
3. 超越函数类指令
    浮点指令集中包含有进行三角函数、指数和对数运算的指令。
4. 浮点比较类指令
    浮点比较指令比较栈顶数据与指定的源操作数，比较结果通过浮点状态寄存器反映。
5. FPU控制类指令
    FPU控制类指令用于控制和检测浮点处理单元FPU的状态及操作方式。

采用浮点指令的汇编语言程序格式，与整数指令源程序格式是类似的，但有以下几点需要注意：
·  使用FPU选择伪指令
      由于汇编程序MASM默认只识别8086指令，所以要加上.8087 / .287 / .387等伪指令选择汇编浮点指令；有时，还要加上相应的.238/.386等伪指令。
·  定义浮点数据
      数据定义伪指令dd(dword) / dq(qword) / dt(tbyte)依次说明32/64/80位数据；它们可以用于定义单精度、双精度和扩展精度浮点数。为了区别于整数定义，MASM 6.11建议采用REAL4、REAL8、REAL10定义单、双、扩展精度浮点数，但不能出现纯整数（其实，整数后面补个小数点就可以了）。相应的数据属性依次是dword、qword、tbyte。另外，实常数可以用E表示10的幂。
·  初始化浮点处理单元
      每当执行一个新的浮点程序时，第一条指令都应该是初始化FPU的指令finit。该指令清除浮点数据寄存器栈和异常，为程序提供一个“干净”的初始状态。否则，遗留在浮点寄存器栈中的数据可能会产生堆栈溢出。另一方面，浮点指令程序段结束，也最好清空浮点数据寄存器。

浮点寄存器:
浮点执行环境的寄存器主要是8个通用数据寄存器和几个专用寄存器，它们是状态寄存器、控制寄存器、标记寄存器等
8个浮点数据寄存器（FPU Data Register），编号FPR0 ~ FPR7。每个浮点寄存器都是80位的，以扩展精度格式存储数据。当其他类型数据压入数据寄存器时，PFU自动转换成扩展精度；相反，数据寄存器的数据取出时，系统也会自动转换成要求的数据类型。
      8个浮点数据寄存器组成首尾相接的堆栈，当前栈顶ST(0)指向的FPRx由状态寄存器中TOP字段指明。数据寄存器不采用随机存取，而是按照“后进先出”的堆栈原则工作，并且首尾循环。向数据寄存器传送（Load）数据时就是入栈，堆栈指针TOP先减1，再将数据压入栈顶寄存器；从数据寄存器取出（Store）数据时就是出栈，先将栈顶寄存器数据弹出，再修改堆栈指针使TOP加1。浮点寄存器栈还有首尾循环相连的特点。例如，若当前栈顶TOP=0（即ST(0) = PFR0），那么，入栈操作后就使TOP=7（即使ST(0) = PFR7），数据被压入PFR7。所以，浮点数据寄存器常常被称为浮点数据栈。
      为了表明浮点数据寄存器中数据的性质，对应每个FPR寄存器，都有一个2位的标记（Tag）位，这8个标记tag0 ~ tag7组成一个16位的标记寄存器。

    首先，至少有一点可以肯定，那就是ANSI C保证结构体中各字段在内存中出现的位置是随它们的声明顺序依次递增的，并且第一个字段的首地址等于整个结构体实例的首地址。比如有这样一个结构体：
 
  struct vector{int x,y,z;} s;
  int *p,*q,*r;
  struct vector *ps;
 
  p = &s.x;
  q = &s.y;
  r = &s.z;
  ps = &s;

  assert(p < q);
  assert(p < r);
  assert(q < r);
  assert((int*)ps == p);
  // 上述断言一定不会失败

    这时，有朋友可能会问:"标准是否规定相邻字段在内存中也相邻?"。 唔，对不起，ANSI C没有做出保证，你的程序在任何时候都不应该依赖这个假设。那这是否意味着我们永远无法勾勒出一幅更清晰更精确的结构体内存布局图？哦，当然不是。不过先让我们从这个问题中暂时抽身，关注一下另一个重要问题————内存对齐。

    许多实际的计算机系统对基本类型数据在内存中存放的位置有限制，它们会要求这些数据的首地址的值是某个数k(通常它为4或8)的倍数，这就是所谓的内存对齐，而这个k则被称为该数据类型的对齐模数(alignment modulus)。当一种类型S的对齐模数与另一种类型T的对齐模数的比值是大于1的整数，我们就称类型S的对齐要求比T强(严格)，而称T比S弱(宽松)。这种强制的要求一来简化了处理器与内存之间传输系统的设计，二来可以提升读取数据的速度。比如这么一种处理器，它每次读写内存的时候都从某个8倍数的地址开始，一次读出或写入8个字节的数据，假如软件能保证double类型的数据都从8倍数地址开始，那么读或写一个double类型数据就只需要一次内存操作。否则，我们就可能需要两次内存操作才能完成这个动作，因为数据或许恰好横跨在两个符合对齐要求的8字节内存块上。某些处理器在数据不满足对齐要求的情况下可能会出错，但是Intel的IA32架构的处理器则不管数据是否对齐都能正确工作。不过Intel奉劝大家，如果想提升性能，那么所有的程序数据都应该尽可能地对齐。Win32平台下的微软C编译器(cl.exe for 80x86)在默认情况下采用如下的对齐规则: 任何基本数据类型T的对齐模数就是T的大小，即sizeof(T)。比如对于double类型(8字节)，就要求该类型数据的地址总是8的倍数，而char类型数据(1字节)则可以从任何一个地址开始。Linux下的GCC奉行的是另外一套规则(在资料中查得，并未验证，如错误请指正):任何2字节大小(包括单字节吗?)的数据类型(比如short)的对齐模数是2，而其它所有超过2字节的数据类型(比如long,double)都以4为对齐模数。

    现在回到我们关心的struct上来。ANSI C规定一种结构类型的大小是它所有字段的大小以及字段之间或字段尾部的填充区大小之和。嗯？填充区？对，这就是为了使结构体字段满足内存对齐要求而额外分配给结构体的空间。那么结构体本身有什么对齐要求吗？有的，ANSI C标准规定结构体类型的对齐要求不能比它所有字段中要求最严格的那个宽松，可以更严格(但此非强制要求，VC7.1就仅仅是让它们一样严格)。我们来看一个例子(以下所有试验的环境是Intel Celeron 2.4G + WIN2000 PRO + vc7.1，内存对齐编译选项是"默认"，即不指定/Zp与/pack选项):

  typedef struct ms1
  {
     char a;
     int b;
  } MS1;

    假设MS1按如下方式内存布局(本文所有示意图中的内存地址从左至右递增):
       _____________________________
       |       |                   |
       |   a   |        b          |
       |       |                   |
       +---------------------------+
 Bytes:    1             4

    因为MS1中有最强对齐要求的是b字段(int)，所以根据编译器的对齐规则以及ANSI C标准，MS1对象的首地址一定是4(int类型的对齐模数)的倍数。那么上述内存布局中的b字段能满足int类型的对齐要求吗？嗯，当然不能。如果你是编译器，你会如何巧妙安排来满足CPU的癖好呢？呵呵，经过1毫秒的艰苦思考，你一定得出了如下的方案：

       _______________________________________
       |       |\\\\\\\\\\\|                 |
       |   a   |\\padding\\|       b         |
       |       |\\\\\\\\\\\|                 |
       +-------------------------------------+
 Bytes:    1         3             4

    这个方案在a与b之间多分配了3个填充(padding)字节，这样当整个struct对象首地址满足4字节的对齐要求时，b字段也一定能满足int型的4字节对齐规定。那么sizeof(MS1)显然就应该是8，而b字段相对于结构体首地址的偏移就是4。非常好理解，对吗？现在我们把MS1中的字段交换一下顺序:

  typedef struct ms2
  {
     int a;
     char b;
  } MS2;

    或许你认为MS2比MS1的情况要简单，它的布局应该就是

       _______________________
       |             |       |
       |     a       |   b   |
       |             |       |
       +---------------------+
 Bytes:      4           1

    因为MS2对象同样要满足4字节对齐规定，而此时a的地址与结构体的首地址相等，所以它一定也是4字节对齐。嗯，分析得有道理，可是却不全面。让我们来考虑一下定义一个MS2类型的数组会出现什么问题。C标准保证，任何类型(包括自定义结构类型)的数组所占空间的大小一定等于一个单独的该类型数据的大小乘以数组元素的个数。换句话说，数组各元素之间不会有空隙。按照上面的方案，一个MS2数组array的布局就是:

|<-    array[1]     ->|<-    array[2]     ->|<- array[3] .....

__________________________________________________________
|             |       |              |      |
|     a       |   b   |      a       |   b  |.............
|             |       |              |      |
+----------------------------------------------------------
Bytes:  4         1          4           1

    当数组首地址是4字节对齐时，array[1].a也是4字节对齐，可是array[2].a呢？array[3].a ....呢？可见这种方案在定义结构体数组时无法让数组中所有元素的字段都满足对齐规定，必须修改成如下形式:

       ___________________________________
       |             |       |\\\\\\\\\\\|
       |     a       |   b   |\\padding\\|
       |             |       |\\\\\\\\\\\|
       +---------------------------------+
 Bytes:      4           1         3

    现在无论是定义一个单独的MS2变量还是MS2数组，均能保证所有元素的所有字段都满足对齐规定。那么sizeof(MS2)仍然是8，而a的偏移为0，b的偏移是4。

    好的，现在你已经掌握了结构体内存布局的基本准则，尝试分析一个稍微复杂点的类型吧。

  typedef struct ms3
  {
     char a;
     short b;
     double c;
  } MS3;

    我想你一定能得出如下正确的布局图:
        
        padding 
           |
      _____v_________________________________
      |   |\|     |\\\\\\\\\|               |
      | a |\|  b  |\padding\|       c       |
      |   |\|     |\\\\\\\\\|               |
      +-------------------------------------+
Bytes:  1  1   2       4            8
          
    sizeof(short)等于2，b字段应从偶数地址开始，所以a的后面填充一个字节，而sizeof(double)等于8，c字段要从8倍数地址开始，前面的a、b字段加上填充字节已经有4 bytes，所以b后面再填充4个字节就可以保证c字段的对齐要求了。sizeof(MS3)等于16，b的偏移是2，c的偏移是8。接着看看结构体中字段还是结构类型的情况:

  typedef struct ms4
  {
     char a;
     MS3 b;
  } MS4;

    MS3中内存要求最严格的字段是c，那么MS3类型数据的对齐模数就与double的一致(为8)，a字段后面应填充7个字节，因此MS4的布局应该是:
       _______________________________________
       |       |\\\\\\\\\\\|                 |
       |   a   |\\padding\\|       b         |
       |       |\\\\\\\\\\\|                 |
       +-------------------------------------+
 Bytes:    1         7             16

    显然，sizeof(MS4)等于24，b的偏移等于8。

    在实际开发中，我们可以通过指定/Zp编译选项来更改编译器的对齐规则。比如指定/Zpn(VC7.1中n可以是1、2、4、8、16)就是告诉编译器最大对齐模数是n。在这种情况下，所有小于等于n字节的基本数据类型的对齐规则与默认的一样，但是大于n个字节的数据类型的对齐模数被限制为n。事实上，VC7.1的默认对齐选项就相当于/Zp8。仔细看看MSDN对这个选项的描述，会发现它郑重告诫了程序员不要在MIPS和Alpha平台上用/Zp1和/Zp2选项，也不要在16位平台上指定/Zp4和/Zp8(想想为什么？)。改变编译器的对齐选项，对照程序运行结果重新分析上面4种结构体的内存布局将是一个很好的复习。

    到了这里，我们可以回答本文提出的最后一个问题了。结构体的内存布局依赖于CPU、操作系统、编译器及编译时的对齐选项，而你的程序可能需要运行在多种平台上，你的源代码可能要被不同的人用不同的编译器编译(试想你为别人提供一个开放源码的库)，那么除非绝对必需，否则你的程序永远也不要依赖这些诡异的内存布局。顺便说一下，如果一个程序中的两个模块是用不同的对齐选项分别编译的，那么它很可能会产生一些非常微妙的错误。如果你的程序确实有很难理解的行为，不防仔细检查一下各个模块的编译选项。

    思考题:请分析下面几种结构体在你的平台上的内存布局，并试着寻找一种合理安排字段声明顺序的方法以尽量节省内存空间。

    A. struct P1 { int a; char b; int c; char d; };
    B. struct P2 { int a; char b; char c; int d; };
    C. struct P3 { short a[3]; char b[3]; };
    D. struct P4 { short a[3]; char *b[3]; };
    E. struct P5 { struct P2 *a; char b; struct P1 a[2];  };

参考资料:

    【1】《深入理解计算机系统(修订版)》，
         (著)Randal E.Bryant; David O'Hallaron，
         (译)龚奕利 雷迎春，
         中国电力出版社，2004
   
    【2】《C: A Reference Manual》(影印版)，
         (著)Samuel P.Harbison; Guy L.Steele，
         人民邮电出版社，2003