OnPaint是对这个消息的反应函数

mfc 的 CWnd::OnPaint 没做什么，只是丢给系统处理。

一 ：

   先执行OnEraseBkgnd，擦除背景（如果想自绘控件，这个函数直接return TRUE就可以了，这样就不会擦除背景，不会闪）

OnEraseBkGnd与OnPaint的区别与联系

在OnEraseBkGnd中,如果你不调用原来缺省的OnEraseBkGnd只是重画背景则不会有闪烁.而在OnPaint里面,由于它隐含的调用了OnEraseBkGnd,而你又没有处理OnEraseBkGnd 函数,这时就和窗口缺省的背景刷相关了.缺省的 OnEraseBkGnd操作使用窗口的缺省背景刷刷新背景(一般情况下是白刷),而随后你又自己重画背景造成屏幕闪动.

OnEraseBkGnd不是每次都会被调用的.如果你调用Invalidate的时候参数为TRUE,那么在OnPaint里面隐含调用BeginPaint的时候就产生WM_ERASEBKGND消息,如果参数是FALSE,则不会重刷背景.

ZYP解释：void Invalidate( BOOL bErase = TRUE ); 该函数的作用是使整个窗口客户区无效。窗口的客户区无效意味着需要重绘，参数bErase为TRUE时，重绘区域内的背景将被重绘即擦除，否则，背景将保持不变。调用Invalidate等函数后窗口不会立即重绘，这是由于WM_PAINT消息的优先级很低，它需要等消息队列中的其它消息发送完后才能被处理。

OnPaint里面会调用BeginPaint函数自动设置显示设备内容的剪切区域而排除任何更新区域外的区域更新区域。如果更新区域被标记为可擦除的，BeginPaint发送一个WM_ERASEBKGND消息给窗口。WM_ERASEBKGND消息的响应函数既是OnEraseBkGnd（）

所以解决方法有三个半:
1.用OnEraseBkGnd实现,不要调用原来的OnEraseBkGnd函数.
2.用OnPaint实现,同时重载OnEraseBkGnd,其中直接返回.
3.用OnPaint实现,创建窗口时设置背景刷为空
4.用OnPaint实现,但是要求刷新时用Invalidate(FALSE)这样
的函数.(不过这种情况下,窗口覆盖等造成的刷新还是要闪一
下,所以不是彻底的解决方法)
都挺简单的.

二 ：

     系统的Onpaint中调用了OnDraw，但如果我们自己继承了一个OnPaint函数又没有显式调用OnDraw，则OnDraw就不会被调用,OnInitialUpdate在OnDraw之前，是窗口被创建以后调用的第一个函数。

MFC中OnDraw与OnPaint的区别

在OnPaint中调用OnDraw，一般来说，用户自己的绘图代码应放在OnDraw中。

OnPaint()是CWnd的类成员，负责响应WM_PAINT消息。OnDraw()是CVIEW的成员函数，没有响应消息的功能.当视图变得无效时（包括大小的改变，移动，被遮盖等等），Windows发送WM_PAINT消息。该视图的OnPaint 处理函数通过创建CPaintDC类的DC对象来响应该消息并调用视图的OnDraw成员函数.OnPaint最后也要调用OnDraw,因此一般在OnDraw函数中进行绘制。

The WM_PAINT message is sent when the UpdateWindow or RedrawWindow member function is called.

在OnPaint中，将调用BeginPaint，用来获得客户区的显示设备环境，并以此调用GDI函数执行绘图操作。在绘图操作完成后，将调用EndPaint以释放显示设备环境。而OnDraw在BeginPaint与EndPaint间被调用。（一个应用程序除了响应WM_PAINT消息外，不应该调用BeginPaint。每次调用BeginPaint都应该有相应的EndPaint函数。）

1) 在mfc结构里OnPaint是CWnd的成员函数. OnDraw是CView的成员函数.
2) OnPaint()调用OnDraw()，OnPrint也会调用OnDraw()，所以OnDraw()是显示和打印的共同操作。

OnPaint是WM_PAINT消息引发的重绘消息处理函数，在OnPaint中会调用OnDraw来进行绘图。OnPaint中首先构造一个CPaintDC类得实例，然后一这个实例为参数来调用虚函数OnPrepareDC来进行一些绘制前的一些处理，比设置映射模式，最后调用OnDraw。而OnDraw和OnPrepareDC不是消息处理函数。所以在不是因为重绘消息所引发的OnPaint导致OnDraw被调用时，比如在OnLButtonDown等消息处理函数中绘图时，要先自己调用OnPrepareDC。
至于CPaintDC和CClientDC根本是两回事情 CPaintDC是一个设备环境类，在OnPaint中作为参数传递给OnPrepareDC来作设备环境的设置。真正和CClientDC具有可比性的是CWindowDC，他们一个是描述客户区域，一个是描述整个屏幕。
如果是对CVIEW或从CVIEW类派生的窗口绘图时应该用OnDraw。

OnDraw()和OnPaint()有什么区别呢？
首先：我们先要明确CView类派生自CWnd类。而OnPaint()是CWnd的类成员，同时负责响应WM_PAINT消息。OnDraw()是CVIEW的成员函数，并且没有响应消息的功能。这就是为什么你用VC成的程序代码时，在视图类只有OnDraw没有OnPaint的原因。而在基于对话框的程序中，只有OnPaint。
其次：我们在第《每天跟我学MFC》3的开始部分已经说到了。要想在屏幕上绘图或显示图形，首先需要建立设备环境DC。其实DC是一个数据结构，它包含输出设备（不单指你17寸的纯屏显示器，还包括打印机之类的输出设备）的绘图属性的描述。MFC提供了CPaintDC类和CWindwoDC类来实时的响应，而CPaintDC支持重画。当视图变得无效时（包括大小的改变，移动，被遮盖等等），Windows 将 WM_PAINT 消息发送给它。该视图的OnPaint 处理函数通过创建 CPaintDC 类的DC对象来响应该消息并调用视图的 OnDraw 成员函数。通常我们不必编写重写的 OnPaint 处理成员函数。
///CView默认的标准的重画函数
void CView::OnPaint() //见VIEWCORE.CPP
{

CPaintDC dc(this);
OnPrepareDC(&dc)；
OnDraw(&dc); //调用了OnDraw
}
///CView默认的标准的OnPrint函数
void CView::OnPrint(CDC* pDC, CPrintInfo*)
{
ASSERT_VALID(pDC);
OnDraw(pDC); // Call Draw
}

既然OnPaint最后也要调用OnDraw,因此我们一般会在OnDraw函数中进行绘制。下面是一个典型的程序。
///视图中的绘图代码首先检索指向文档的指针，然后通过DC进行绘图调用。
void CMyView::OnDraw( CDC* pDC )
{

CMyDoc* pDoc = GetDocument();
CString s = pDoc->GetData();
GetClientRect( &rect ); // Returns a CString CRect rect;
pDC->SetTextAlign( TA_BASELINE | TA_CENTER );
pDC->TextOut( rect.right / 2, rect.bottom / 2, s, s.GetLength() );
}
最后：现在大家明白这哥俩之间的关系了吧。因此我们一般用OnPaint维护窗口的客户区（例如我们的窗口客户区加一个背景图片），用OnDraw维护视图的客户区（例如我们通过鼠标在视图中画图）。当然你也可以不按照上面规律来，只要达到目的并且没有问题，怎么干都成。补充：我们还可以利用Invalidate(),ValidateRgn(),ValidateRect()函数强制的重画窗口，具体的请参考MSDN吧。

OnDraw中可以绘制用户区域。OnPaint中只是当窗口无效时重绘不会保留CClientDC绘制的内容。

这两个函数有区别也有联系：

1、区别：OnDraw是一个纯虚函数，定义为virtual void OnDraw( CDC* pDC ) = 0;　而OnPaint是一个消息响应函数，它响应了WM＿PANIT消息，也是是窗口重绘消息。

2、联系：我们一般在视类中作图的时候，往往不直接响应WM＿PANIT消息，而是重载OnDraw纯虚函数，这是因为在CVIEW类中的WM＿PANIT消息响应函数中调用了OnDraw函数，如果在CMYVIEW类中响应了WM＿PAINT消息，不显式地调用OnDraw函数的话，是不会在窗口重绘的时候调用OnDraw函数的。

应用程序中几乎所有的绘图都在视图的 OnDraw 成员函数中发生，必须在视图类中重写该成员函数。（鼠标绘图是个特例，这在通过视图解释用户输入中讨论。）

OnDraw 重写：
通过调用您提供的文档成员函数获取数据。
通过调用框架传递给 OnDraw 的设备上下文对象的成员函数来显示数据。
当文档的数据以某种方式更改后，必须重绘视图以反映该更改。默认的 OnUpdate 实现使视图的整个工作区无效。当视图变得无效时，Windows 将 WM_PAINT 消息发送给它。该视图的 OnPaint 处理函数通过创建 CPaintDC 类的设备上下文对象来响应该消息并调用视图的 OnDraw 成员函数。

当没有添加WM_PAINT消息处理时,窗口重绘时,由OnDraw来进行消息响应...当添加WM_PAINT消息处理时,窗口重绘时,WM_PAINT消息被投递,由OnPaint来进行消息响应.这时就不能隐式调用OnDraw了.必须显式调用( CDC *pDC=GetDC(); OnDraw(pDC); )..
隐式调用:当由OnPaint来进行消息响应时,系统自动调用CView::OnDraw(&pDC).

想象一下，窗口显示的内容和打印的内容是差不多的，所以，一般情况下，统一由OnDraw来画。窗口前景需要刷新时，系统会会调用到OnPaint，而OnPaint一般情况下是对DC作一些初始化操作后，调用OnDraw()。

OnEraseBkGnd()，是窗口背景需要刷新时由系统调用的。明显的一个例子是设置窗口的背景颜色（你可以把这放在OnPaint中去做，但是会使产生闪烁的现象）。
至于怎么界定背景和前景，那要具体问题具体分析了，一般情况下，你还是很容易区别的吧。

的确，OnPaint()用来响应WM_PAINT消息，视类的OnPaint()内部根据是打印还是屏幕绘制分别以不同的参数调用OnDraw()虚函数。所以在OnDraw()里你可以区别对待打印和屏幕绘制。
其实，MFC在进行打印前后还做了很多工作，调用了很多虚函数，比如OnPreparePrint()等。

另外OnInitialUpdate

视图窗口完全建立后第一个被框架调用的函数。框架在第一次调用OnDraw前会调用OnInitialUpdate，因此OnInitialUpdate是设置滚动视图的逻辑尺寸和映射模式的最合适的地方。

0 Makefile概述

因为，makefile关系到了整个工程的编译规则。一个工程中的源文件不计数，其按类型、功能、模块分别放在若干个目录中，makefile定义了一系列的规则来指定，哪些文件需要先编译，哪些文件需要后编译，哪些文件需要重新编译，甚至于进行更复杂的功能操作，因为makefile就像一个Shell脚本一样，其中也可以执行操作系统的命令。

makefile带来的好处就是——“自动化编译”，一旦写好，只需要一个make命令，整个工程完全自动编译，极大的提高了软件开发的效率。make是一个命令工具，是一个解释makefile中指令的命令工具，一般来说，大多数的IDE都有这个命令，比如：Delphi的make，Visual C++的nmake，Linux下GNU的make。可见，makefile都成为了一种在工程方面的编译方法。

现在讲述如何写makefile的文章比较少，这是我想写这篇文章的原因。当然，不同产商的make各不相同，也有不同的语法，但其本质都是在“文件依赖性”上做文章，这里，我仅对GNU的make进行讲述，我的环境是RedHat Linux 8.0，make的版本是3.80。必竟，这个make是应用最为广泛的，也是用得最多的。而且其还是最遵循于IEEE 1003.2-1992 标准的（POSIX.2）。

在这篇文档中，将以C/C++的源码作为我们基础，所以必然涉及一些关于C/C++的编译的知识，相关于这方面的内容，还请各位查看相关的编译器的文档。这里所默认的编译器是UNIX下的GCC和CC。

0.1 关于程序的编译和链接

编译时，编译器需要的是语法的正确，函数与变量的声明的正确。对于后者，通常是你需要告诉编译器头文件的所在位置（头文件中应该只是声明，而定义应该放在C/C++文件中），只要所有的语法正确，编译器就可以编译出中间目标文件。一般来说，每个源文件都应该对应于一个中间目标文件（O文件或是OBJ文件）。

链接时，主要是链接函数和全局变量，所以，我们可以使用这些中间目标文件（O文件或是OBJ文件）来链接我们的应用程序。链接器并不管函数所在的源文件，只管函数的中间目标文件（Object File），在大多数时候，由于源文件太多，编译生成的中间目标文件太多，而在链接时需要明显地指出中间目标文件名，这对于编译很不方便，所以，我们要给中间目标文件打个包，在Windows下这种包叫“库文件”（Library File)，也就是 .lib 文件，在UNIX下，是Archive File，也就是 .a 文件。

总结一下，源文件首先会生成中间目标文件，再由中间目标文件生成执行文件。在编译时，编译器只检测程序语法，和函数、变量是否被声明。如果函数未被声明，编译器会给出一个警告，但可以生成Object File。而在链接程序时，链接器会在所有的Object File中找寻函数的实现，如果找不到，那到就会报链接错误码（Linker Error），在VC下，这种错误一般是：Link 2001错误，意思说是说，链接器未能找到函数的实现。你需要指定函数的Object File.

好，言归正传，GNU的make有许多的内容，闲言少叙，还是让我们开始吧。

1 Makefile 介绍

首先，我们用一个示例来说明Makefile的书写规则。以便给大家一个感兴认识。这个示例来源于GNU的make使用手册，在这个示例中，我们的工程有8个C文件，和3个头文件，我们要写一个Makefile来告诉make命令如何编译和链接这几个文件。我们的规则是：

1. 如果这个工程没有编译过，那么我们的所有C文件都要编译并被链接。
2. 如果这个工程的某几个C文件被修改，那么我们只编译被修改的C文件，并链接目标程序。
3. 如果这个工程的头文件被改变了，那么我们需要编译引用了这几个头文件的C文件，并链接目标程序。

只要我们的Makefile写得够好，所有的这一切，我们只用一个make命令就可以完成，make命令会自动智能地根据当前的文件修改的情况来确定哪些文件需要重编译，从而自己编译所需要的文件和链接目标程序。

1.1 Makefile的规则

target ... : prerequisites ...
command
...
...

prerequisites就是，要生成那个target所需要的文件或是目标。

command也就是make需要执行的命令。（任意的Shell命令）

这是一个文件的依赖关系，也就是说，target这一个或多个的目标文件依赖于prerequisites中的文件，其生成规则定义在command中。说白一点就是说，prerequisites中如果有一个以上的文件比target文件要新的话，command所定义的命令就会被执行。这就是Makefile的规则。也就是Makefile中最核心的内容。

说到底，Makefile的东西就是这样一点，好像我的这篇文档也该结束了。呵呵。还不尽然，这是Makefile的主线和核心，但要写好一个Makefile还不够，我会以后面一点一点地结合我的工作经验给你慢慢到来。内容还多着呢。：）

1.2 一个示例

    edit : main.o kbd.o command.o display.o \
insert.o search.o files.o utils.o
cc -o edit main.o kbd.o command.o display.o \
insert.o search.o files.o utils.o
main.o : main.c defs.h
cc -c main.c
kbd.o : kbd.c defs.h command.h
cc -c kbd.c
command.o : command.c defs.h command.h
cc -c command.c
display.o : display.c defs.h buffer.h
cc -c display.c
insert.o : insert.c defs.h buffer.h
cc -c insert.c
search.o : search.c defs.h buffer.h
cc -c search.c
files.o : files.c defs.h buffer.h command.h
cc -c files.c
utils.o : utils.c defs.h
cc -c utils.c
clean :
rm edit main.o kbd.o command.o display.o \
insert.o search.o files.o utils.o

在这个makefile中，目标文件（target）包含：执行文件edit和中间目标文件（*.o），依赖文件（prerequisites）就是冒号后面的那些 .c 文件和 .h文件。每一个 .o 文件都有一组依赖文件，而这些 .o 文件又是执行文件 edit 的依赖文件。依赖关系的实质上就是说明了目标文件是由哪些文件生成的，换言之，目标文件是哪些文件更新的。

在定义好依赖关系后，后续的那一行定义了如何生成目标文件的操作系统命令，一定要以一个Tab键作为开头。记住，make并不管命令是怎么工作的，他只管执行所定义的命令。make会比较targets文件和prerequisites文件的修改日期，如果prerequisites文件的日期要比targets文件的日期要新，或者target不存在的话，那么，make就会执行后续定义的命令。

这里要说明一点的是，clean不是一个文件，它只不过是一个动作名字，有点像C语言中的lable一样，其冒号后什么也没有，那么，make就不会自动去找文件的依赖性，也就不会自动执行其后所定义的命令。要执行其后的命令，就要在make命令后明显得指出这个lable的名字。这样的方法非常有用，我们可以在一个makefile中定义不用的编译或是和编译无关的命令，比如程序的打包，程序的备份，等等。

1.3 make是如何工作的

1. make会在当前目录下找名字叫“Makefile”或“makefile”的文件。
2. 如果找到，它会找文件中的第一个目标文件（target），在上面的例子中，他会找到“edit”这个文件，并把这个文件作为最终的目标文件。
3. 如果edit文件不存在，或是edit所依赖的后面的 .o 文件的文件修改时间要比edit这个文件新，那么，他就会执行后面所定义的命令来生成edit这个文件。
4. 如果edit所依赖的.o文件也存在，那么make会在当前文件中找目标为.o文件的依赖性，如果找到则再根据那一个规则生成.o文件。（这有点像一个堆栈的过程）
5. 当然，你的C文件和H文件是存在的啦，于是make会生成 .o 文件，然后再用 .o 文件生命make的终极任务，也就是执行文件edit了。

这就是整个make的依赖性，make会一层又一层地去找文件的依赖关系，直到最终编译出第一个目标文件。在找寻的过程中，如果出现错误，比如最后被依赖的文件找不到，那么make就会直接退出，并报错，而对于所定义的命令的错误，或是编译不成功，make根本不理。make只管文件的依赖性，即，如果在我找了依赖关系之后，冒号后面的文件还是不在，那么对不起，我就不工作啦。

通过上述分析，我们知道，像clean这种，没有被第一个目标文件直接或间接关联，那么它后面所定义的命令将不会被自动执行，不过，我们可以显示要make执行。即命令——“make clean”，以此来清除所有的目标文件，以便重编译。

于是在我们编程中，如果这个工程已被编译过了，当我们修改了其中一个源文件，比如file.c，那么根据我们的依赖性，我们的目标file.o会被重编译（也就是在这个依性关系后面所定义的命令），于是file.o的文件也是最新的啦，于是file.o的文件修改时间要比edit要新，所以edit也会被重新链接了（详见edit目标文件后定义的命令）。

而如果我们改变了“command.h”，那么，kdb.o、command.o和files.o都会被重编译，并且，edit会被重链接。

1.4 makefile中使用变量

      edit : main.o kbd.o command.o display.o \
insert.o search.o files.o utils.o
cc -o edit main.o kbd.o command.o display.o \
insert.o search.o files.o utils.o

比如，我们声明一个变量，叫objects, OBJECTS, objs, OBJS, obj, 或是 OBJ，反正不管什么啦，只要能够表示obj文件就行了。我们在makefile一开始就这样定义：

     objects = main.o kbd.o command.o display.o \
insert.o search.o files.o utils.o

    objects = main.o kbd.o command.o display.o \
insert.o search.o files.o utils.o
edit : $(objects)
cc -o edit $(objects)
main.o : main.c defs.h
cc -c main.c
kbd.o : kbd.c defs.h command.h
cc -c kbd.c
command.o : command.c defs.h command.h
cc -c command.c
display.o : display.c defs.h buffer.h
cc -c display.c
insert.o : insert.c defs.h buffer.h
cc -c insert.c
search.o : search.c defs.h buffer.h
cc -c search.c
files.o : files.c defs.h buffer.h command.h
cc -c files.c
utils.o : utils.c defs.h
cc -c utils.c
clean :
rm edit $(objects)

于是如果有新的 .o 文件加入，我们只需简单地修改一下 objects 变量就可以了。

关于变量更多的话题，我会在后续给你一一道来。

1.5 让make自动推导

只要make看到一个[.o]文件，它就会自动的把[.c]文件加在依赖关系中，如果make找到一个whatever.o，那么whatever.c，就会是whatever.o的依赖文件。并且 cc -c whatever.c 也会被推导出来，于是，我们的makefile再也不用写得这么复杂。我们的是新的makefile又出炉了。

    objects = main.o kbd.o command.o display.o \
insert.o search.o files.o utils.o
edit : $(objects)
cc -o edit $(objects)
main.o : defs.h
kbd.o : defs.h command.h
command.o : defs.h command.h
display.o : defs.h buffer.h
insert.o : defs.h buffer.h
search.o : defs.h buffer.h
files.o : defs.h buffer.h command.h
utils.o : defs.h
.PHONY : clean
clean :
rm edit $(objects)

关于更为详细的“隐晦规则”和“伪目标文件”，我会在后续给你一一道来。

1.6 另类风格的makefile

    objects = main.o kbd.o command.o display.o \
insert.o search.o files.o utils.o
edit : $(objects)
cc -o edit $(objects)
$(objects) : defs.h
kbd.o command.o files.o : command.h
display.o insert.o search.o files.o : buffer.h
.PHONY : clean
clean :
rm edit $(objects)

1.7 清空目标文件的规则

        clean:
rm edit $(objects)

        .PHONY : clean
clean :
-rm edit $(objects)

上面就是一个makefile的概貌，也是makefile的基础，下面还有很多makefile的相关细节，准备好了吗？准备好了就来。

2 Makefile 总述

2.1 Makefile里有什么？

1. 显式规则。显式规则说明了，如何生成一个或多的的目标文件。这是由Makefile的书写者明显指出，要生成的文件，文件的依赖文件，生成的命令。
2. 隐晦规则。由于我们的make有自动推导的功能，所以隐晦的规则可以让我们比较粗糙地简略地书写Makefile，这是由make所支持的。
3. 变量的定义。在Makefile中我们要定义一系列的变量，变量一般都是字符串，这个有点你C语言中的宏，当Makefile被执行时，其中的变量都会被扩展到相应的引用位置上。
4. 文件指示。其包括了三个部分，一个是在一个Makefile中引用另一个Makefile，就像C语言中的include一样；另一个是指根据某些情况指定Makefile中的有效部分，就像C语言中的预编译#if一样；还有就是定义一个多行的命令。有关这一部分的内容，我会在后续的部分中讲述。
5. 注释。Makefile中只有行注释，和UNIX的Shell脚本一样，其注释是用“#”字符，这个就像C/C++中的“//”一样。如果你要在你的Makefile中使用“#”字符，可以用反斜框进行转义，如：“\#”。

最后，还值得一提的是，在Makefile中的命令，必须要以[Tab]键开始。

2.2Makefile的文件名

当然，你可以使用别的文件名来书写Makefile，比如：“Make.Linux”，“Make.Solaris”，“Make.AIX”等，如果要指定特定的Makefile，你可以使用make的“-f”和“--file”参数，如：make -f Make.Linux或make --file Make.AIX。

2.3 引用其它的Makefile

include <filename>

在include前面可以有一些空字符，但是绝不能是[Tab]键开始。include和可以用一个或多个空格隔开。举个例子，你有这样几个Makefile：a.mk、b.mk、c.mk，还有一个文件叫foo.make，以及一个变量$(bar)，其包含了e.mk和f.mk，那么，下面的语句：

    include foo.make *.mk $(bar)

    include foo.make a.mk b.mk c.mk e.mk f.mk

1. 如果make执行时，有“-I”或“--include-dir”参数，那么make就会在这个参数所指定的目录下去寻找。
2. 如果目录 /include（一般是：/usr/local/bin或/usr/include）存在的话，make也会去找。

如果有文件没有找到的话，make会生成一条警告信息，但不会马上出现致命错误。它会继续载入其它的文件，一旦完成makefile的读取，make会再重试这些没有找到，或是不能读取的文件，如果还是不行，make才会出现一条致命信息。如果你想让make不理那些无法读取的文件，而继续执行，你可以在include前加一个减号“-”。如：

-include <filename>

2.4 环境变量 MAKEFILES

但是在这里我还是建议不要使用这个环境变量，因为只要这个变量一被定义，那么当你使用make时，所有的Makefile都会受到它的影响，这绝不是你想看到的。在这里提这个事，只是为了告诉大家，也许有时候你的Makefile出现了怪事，那么你可以看看当前环境中有没有定义这个变量。

2.5 make的工作方式

1. 读入所有的Makefile。
2. 读入被include的其它Makefile。
3. 初始化文件中的变量。
4. 推导隐晦规则，并分析所有规则。
5. 为所有的目标文件创建依赖关系链。
6. 根据依赖关系，决定哪些目标要重新生成。
7. 执行生成命令。

1-5步为第一个阶段，6-7为第二个阶段。第一个阶段中，如果定义的变量被使用了，那么，make会把其展开在使用的位置。但make并不会完全马上展开，make使用的是拖延战术，如果变量出现在依赖关系的规则中，那么仅当这条依赖被决定要使用了，变量才会在其内部展开。

当然，这个工作方式你不一定要清楚，但是知道这个方式你也会对make更为熟悉。有了这个基础，后续部分也就容易看懂了。

3 Makefile书写规则

在Makefile中，规则的顺序是很重要的，因为，Makefile中只应该有一个最终目标，其它的目标都是被这个目标所连带出来的，所以一定要让make知道你的最终目标是什么。一般来说，定义在Makefile中的目标可能会有很多，但是第一条规则中的目标将被确立为最终的目标。如果第一条规则中的目标有很多个，那么，第一个目标会成为最终的目标。make所完成的也就是这个目标。

好了，还是让我们来看一看如何书写规则。

3.1 规则举例

 foo.o : foo.c defs.h       # foo模块
cc -c -g foo.c

1. 文件的依赖关系，foo.o依赖于foo.c和defs.h的文件，如果foo.c和defs.h的文件日期要比foo.o文件日期要新，或是foo.o不存在，那么依赖关系发生。
2. 如果生成（或更新）foo.o文件。也就是那个cc命令，其说明了，如何生成foo.o这个文件。（当然foo.c文件include了defs.h文件）

3.2 规则的语法

      targets : prerequisites
command
...

      targets : prerequisites ; command
command
...

command是命令行，如果其不与“target:prerequisites”在一行，那么，必须以[Tab键]开头，如果和prerequisites在一行，那么可以用分号做为分隔。（见上）

prerequisites也就是目标所依赖的文件（或依赖目标）。如果其中的某个文件要比目标文件要新，那么，目标就被认为是“过时的”，被认为是需要重生成的。这个在前面已经讲过了。

如果命令太长，你可以使用反斜框（‘\’）作为换行符。make对一行上有多少个字符没有限制。规则告诉make两件事，文件的依赖关系和如何成成目标文件。

一般来说，make会以UNIX的标准Shell，也就是/bin/sh来执行命令。

3.3 在规则中使用通配符

如果我们想定义一系列比较类似的文件，我们很自然地就想起使用通配符。make支持三各通配符：“*”，“?”和“[...]”。这是和Unix的B-Shell是相同的。

波浪号（“~”）字符在文件名中也有比较特殊的用途。如果是“~/test”，这就表示当前用户的$HOME目录下的test目录。而“~hchen/test”则表示用户hchen的宿主目录下的test目录。（这些都是Unix下的小知识了，make也支持）而在Windows或是MS-DOS下，用户没有宿主目录，那么波浪号所指的目录则根据环境变量“HOME”而定。

通配符代替了你一系列的文件，如“*.c”表示所以后缀为c的文件。一个需要我们注意的是，如果我们的文件名中有通配符，如：“*”，那么可以用转义字符“\”，如“\*”来表示真实的“*”字符，而不是任意长度的字符串。

好吧，还是先来看几个例子吧：

    clean:
rm -f *.o

    print: *.c
lpr -p $?
touch print

    objects = *.o

    objects := $(wildcard *.o)

3.4 文件搜寻

在一些大的工程中，有大量的源文件，我们通常的做法是把这许多的源文件分类，并存放在不同的目录中。所以，当make需要去找寻文件的依赖关系时，你可以在文件前加上路径，但最好的方法是把一个路径告诉make，让make在自动去找。

Makefile文件中的特殊变量“VPATH”就是完成这个功能的，如果没有指明这个变量，make只会在当前的目录中去找寻依赖文件和目标文件。如果定义了这个变量，那么，make就会在当当前目录找不到的情况下，到所指定的目录中去找寻文件了。

    VPATH = src:../headers

另一个设置文件搜索路径的方法是使用make的“vpath”关键字（注意，它是全小写的），这不是变量，这是一个make的关键字，这和上面提到的那个VPATH变量很类似，但是它更为灵活。它可以指定不同的文件在不同的搜索目录中。这是一个很灵活的功能。它的使用方法有三种：

1. vpath < pattern> < directories>
   为符合模式< pattern>的文件指定搜索目录< directories>。
2. vpath < pattern>
   清除符合模式< pattern>的文件的搜索目录。
3. vpath
   清除所有已被设置好了的文件搜索目录。

vapth使用方法中的< pattern>需要包含“%”字符。“%”的意思是匹配零或若干字符，例如，“%.h”表示所有以“.h”结尾的文件。< pattern>指定了要搜索的文件集，而< directories>则指定了 的文件集的搜索的目录。例如：

    vpath %.h ../headers

我们可以连续地使用vpath语句，以指定不同搜索策略。如果连续的vpath语句中出现了相同的< pattern>，或是被重复了的< pattern>，那么，make会按照vpath语句的先后顺序来执行搜索。如：

    vpath %.c foo
vpath %   blish
vpath %.c bar

    vpath %.c foo:bar
vpath %   blish

3.5 伪目标

最早先的一个例子中，我们提到过一个“clean”的目标，这是一个“伪目标”，

    clean:
rm *.o temp

因为，我们并不生成“clean”这个文件。“伪目标”并不是一个文件，只是一个标签，由于“伪目标”不是文件，所以make无法生成它的依赖关系和决定它是否要执行。我们只有通过显示地指明这个“目标”才能让其生效。当然，“伪目标”的取名不能和文件名重名，不然其就失去了“伪目标”的意义了。

当然，为了避免和文件重名的这种情况，我们可以使用一个特殊的标记“.PHONY”来显示地指明一个目标是“伪目标”，向make说明，不管是否有这个文件，这个目标就是“伪目标”。

    .PHONY : clean

     .PHONY: clean
clean:
rm *.o temp

    all : prog1 prog2 prog3
.PHONY : all
prog1 : prog1.o utils.o
cc -o prog1 prog1.o utils.o
prog2 : prog2.o
cc -o prog2 prog2.o
prog3 : prog3.o sort.o utils.o
cc -o prog3 prog3.o sort.o utils.o

随便提一句，从上面的例子我们可以看出，目标也可以成为依赖。所以，伪目标同样也可成为依赖。看下面的例子：

    .PHONY: cleanall cleanobj cleandiff
cleanall : cleanobj cleandiff
rm program
cleanobj :
rm *.o
cleandiff :
rm *.diff

3.6 多目标

Makefile的规则中的目标可以不止一个，其支持多目标，有可能我们的多个目标同时依赖于一个文件，并且其生成的命令大体类似。于是我们就能把其合并起来。当然，多个目标的生成规则的执行命令是同一个，这可能会可我们带来麻烦，不过好在我们的可以使用一个自动化变量“$@”（关于自动化变量，将在后面讲述），这个变量表示着目前规则中所有的目标的集合，这样说可能很抽象，还是看一个例子吧。

    bigoutput littleoutput : text.g
generate text.g -$(subst output,,$@) > $@
    上述规则等价于：

bigoutput : text.g
generate text.g -big > bigoutput
littleoutput : text.g
generate text.g -little > littleoutput

3.7 静态模式

静态模式可以更加容易地定义多目标的规则，可以让我们的规则变得更加的有弹性和灵活。我们还是先来看一下语法：

<targets ...>: <target-pattern>: <prereq-patterns ...>
　　　<commands>
...

targets定义了一系列的目标文件，可以有通配符。是目标的一个集合。

target-parrtern是指明了targets的模式，也就是的目标集模式。

prereq-parrterns是目标的依赖模式，它对target-parrtern形成的模式再进行一次依赖目标的定义。

这样描述这三个东西，可能还是没有说清楚，还是举个例子来说明一下吧。如果我们的<target-parrtern>定义成“%.o”，意思是我们的集合中都是以“.o”结尾的，而如果我们的<prereq-parrterns>定义成“%.c”，意思是对<target-parrtern>所形成的目标集进行二次定义，其计算方法是，取<target-parrtern>模式中的“%”（也就是去掉了[.o]这个结尾），并为其加上[.c]这个结尾，形成的新集合。

所以，我们的“目标模式”或是“依赖模式”中都应该有“%”这个字符，如果你的文件名中有“%”那么你可以使用反斜杠“\”进行转义，来标明真实的“%”字符。

看一个例子：

    objects = foo.o bar.o
all: $(objects)
$(objects): %.o: %.c
$(CC) -c $(CFLAGS) $< -o $@

    foo.o : foo.c
$(CC) -c $(CFLAGS) foo.c -o foo.o
bar.o : bar.c
$(CC) -c $(CFLAGS) bar.c -o bar.o

    files = foo.elc bar.o lose.o
$(filter %.o,$(files)): %.o: %.c
$(CC) -c $(CFLAGS) $< -o $@
$(filter %.elc,$(files)): %.elc: %.el
emacs -f batch-byte-compile $<

$(filter %.o,$(files))表示调用Makefile的filter函数，过滤“$filter”集，只要其中模式为“%.o”的内容。其的它内容，我就不用多说了吧。这个例字展示了Makefile中更大的弹性。

3.8 自动生成依赖性

在Makefile中，我们的依赖关系可能会需要包含一系列的头文件，比如，如果我们的main.c中有一句“#include "defs.h"”，那么我们的依赖关系应该是：

    main.o : main.c defs.h

    cc -M main.c

    main.o : main.c defs.h

gcc -M main.c的输出是：

    main.o: main.c defs.h /usr/include/stdio.h /usr/include/features.h \
/usr/include/sys/cdefs.h /usr/include/gnu/stubs.h \
/usr/lib/gcc-lib/i486-suse-linux/2.95.3/include/stddef.h \
/usr/include/bits/types.h /usr/include/bits/pthreadtypes.h \
/usr/include/bits/sched.h /usr/include/libio.h \
/usr/include/_G_config.h /usr/include/wchar.h \
/usr/include/bits/wchar.h /usr/include/gconv.h \
/usr/lib/gcc-lib/i486-suse-linux/2.95.3/include/stdarg.h \
/usr/include/bits/stdio_lim.h

    main.o: main.c defs.h

于是，我们可以写出[.c]文件和[.d]文件的依赖关系，并让make自动更新或自成[.d]文件，并把其包含在我们的主Makefile中，这样，我们就可以自动化地生成每个文件的依赖关系了。

这里，我们给出了一个模式规则来产生[.d]文件：

    %.d: %.c
@set -e; rm -f $@; \
$(CC) -M $(CPPFLAGS) $< > $@.$$$$; \
sed 's,\($*\)\.o[ :]*,\1.o $@ : ,g' < $@.$$$$ > $@; \
rm -f $@.$$$$

这个规则的意思是，所有的[.d]文件依赖于[.c]文件，“rm -f $@”的意思是删除所有的目标，也就是[.d]文件，第二行的意思是，为每个依赖文件“$<”，也就是[.c]文件生成依赖文件，“$@”表示模式“%.d”文件，如果有一个C文件是name.c，那么“%”就是“name”，“$$$$”意为一个随机编号，第二行生成的文件有可能是“name.d.12345”，第三行使用sed命令做了一个替换，关于sed命令的用法请参看相关的使用文档。第四行就是删除临时文件。

总而言之，这个模式要做的事就是在编译器生成的依赖关系中加入[.d]文件的依赖，即把依赖关系：

    main.o : main.c defs.h

    main.o main.d : main.c defs.h

    sources = foo.c bar.c
include $(sources:.c=.d)

.d]文件中的目标会成为默认目标

4 Makefile 书写命令

---

每条规则中的命令和操作系统Shell的命令行是一致的。make会一按顺序一条一条的执行命令，每条命令的开头必须以[Tab]键开头，除非，命令是紧跟在依赖规则后面的分号后的。在命令行之间中的空格或是空行会被忽略，但是如果该空格或空行是以Tab键开头的，那么make会认为其是一个空命令。

我们在UNIX下可能会使用不同的Shell，但是make的命令默认是被“/bin/sh”——UNIX的标准Shell解释执行的。除非你特别指定一个其它的Shell。Makefile中，“#”是注释符，很像C/C++中的“//”，其后的本行字符都被注释。

4.1 显示命令

通常，make会把其要执行的命令行在命令执行前输出到屏幕上。当我们用“@”字符在命令行前，那么，这个命令将不被make显示出来，最具代表性的例子是，我们用这个功能来像屏幕显示一些信息。如：

    @echo 正在编译XXX模块......

当make执行时，会输出“正在编译XXX模块......”字串，但不会输出命令，如果没有“@”，那么，make将输出：

    echo 正在编译XXX模块......
正在编译XXX模块......

如果make执行时，带入make参数“-n”或“--just-print”，那么其只是显示命令，但不会执行命令，这个功能很有利于我们调试我们的Makefile，看看我们书写的命令是执行起来是什么样子的或是什么顺序的。

而make参数“-s”或“--slient”则是全面禁止命令的显示。

4.2 命令执行

当依赖目标新于目标时，也就是当规则的目标需要被更新时，make会一条一条的执行其后的命令。需要注意的是，如果你要让上一条命令的结果应用在下一条命令时，你应该使用分号分隔这两条命令。比如你的第一条命令是cd命令，你希望第二条命令得在cd之后的基础上运行，那么你就不能把这两条命令写在两行上，而应该把这两条命令写在一行上，用分号分隔。如：

    示例一：
exec:
cd /home/hchen
pwd
示例二：
exec:
cd /home/hchen; pwd

当我们执行“make exec”时，第一个例子中的cd没有作用，pwd会打印出当前的Makefile目录，而第二个例子中，cd就起作用了，pwd会打印出“/home/hchen”。

make一般是使用环境变量SHELL中所定义的系统Shell来执行命令，默认情况下使用UNIX的标准Shell——/bin/sh来执行命令。但在MS-DOS下有点特殊，因为MS-DOS下没有SHELL环境变量，当然你也可以指定。如果你指定了UNIX风格的目录形式，首先，make会在SHELL所指定的路径中找寻命令解释器，如果找不到，其会在当前盘符中的当前目录中寻找，如果再找不到，其会在PATH环境变量中所定义的所有路径中寻找。MS-DOS中，如果你定义的命令解释器没有找到，其会给你的命令解释器加上诸如“.exe”、“.com”、“.bat”、“.sh”等后缀。

4.3 命令出错

每当命令运行完后，make会检测每个命令的返回码，如果命令返回成功，那么make会执行下一条命令，当规则中所有的命令成功返回后，这个规则就算是成功完成了。如果一个规则中的某个命令出错了（命令退出码非零），那么make就会终止执行当前规则，这将有可能终止所有规则的执行。

有些时候，命令的出错并不表示就是错误的。例如mkdir命令，我们一定需要建立一个目录，如果目录不存在，那么mkdir就成功执行，万事大吉，如果目录存在，那么就出错了。我们之所以使用mkdir的意思就是一定要有这样的一个目录，于是我们就不希望mkdir出错而终止规则的运行。

为了做到这一点，忽略命令的出错，我们可以在Makefile的命令行前加一个减号“-”（在Tab键之后），标记为不管命令出不出错都认为是成功的。如：

   clean:
-rm -f *.o

还有一个全局的办法是，给make加上“-i”或是“--ignore-errors”参数，那么，Makefile中所有命令都会忽略错误。而如果一个规则是以“.IGNORE”作为目标的，那么这个规则中的所有命令将会忽略错误。这些是不同级别的防止命令出错的方法，你可以根据你的不同喜欢设置。

还有一个要提一下的make的参数的是“-k”或是“--keep-going”，这个参数的意思是，如果某规则中的命令出错了，那么就终目该规则的执行，但继续执行其它规则。

4.4 嵌套执行make

在一些大的工程中，我们会把我们不同模块或是不同功能的源文件放在不同的目录中，我们可以在每个目录中都书写一个该目录的Makefile，这有利于让我们的Makefile变得更加地简洁，而不至于把所有的东西全部写在一个Makefile中，这样会很难维护我们的Makefile，这个技术对于我们模块编译和分段编译有着非常大的好处。

例如，我们有一个子目录叫subdir，这个目录下有个Makefile文件，来指明了这个目录下文件的编译规则。那么我们总控的Makefile可以这样书写：

    subsystem:
cd subdir && $(MAKE)
其等价于：
subsystem:
$(MAKE) -C subdir

定义$(MAKE)宏变量的意思是，也许我们的make需要一些参数，所以定义成一个变量比较利于维护。这两个例子的意思都是先进入“subdir”目录，然后执行make命令。

我们把这个Makefile叫做“总控Makefile”，总控Makefile的变量可以传递到下级的Makefile中（如果你显示的声明），但是不会覆盖下层的Makefile中所定义的变量，除非指定了“-e”参数。

如果你要传递变量到下级Makefile中，那么你可以使用这样的声明：

export <variable ...>

如果你不想让某些变量传递到下级Makefile中，那么你可以这样声明：

unexport <variable ...>

如：

示例一：
export variable = value
其等价于：
variable = value
export variable
其等价于：
export variable := value
其等价于：
variable := value
export variable
示例二：
export variable += value
其等价于：
variable += value
export variable

如果你要传递所有的变量，那么，只要一个export就行了。后面什么也不用跟，表示传递所有的变量。

需要注意的是，有两个变量，一个是SHELL，一个是MAKEFLAGS，这两个变量不管你是否export，其总是要传递到下层Makefile中，特别是MAKEFILES变量，其中包含了make的参数信息，如果我们执行“总控Makefile”时有make参数或是在上层Makefile中定义了这个变量，那么MAKEFILES变量将会是这些参数，并会传递到下层Makefile中，这是一个系统级的环境变量。

但是make命令中的有几个参数并不往下传递，它们是“-C”,“-f”,“-h”“-o”和“-W”（有关Makefile参数的细节将在后面说明），如果你不想往下层传递参数，那么，你可以这样来：

subsystem:
cd subdir && $(MAKE) MAKEFLAGS=

如果你定义了环境变量MAKEFLAGS，那么你得确信其中的选项是大家都会用到的，如果其中有“-t”,“-n”,和“-q”参数，那么将会有让你意想不到的结果，或许会让你异常地恐慌。

还有一个在“嵌套执行”中比较有用的参数，“-w”或是“--print-directory”会在make的过程中输出一些信息，让你看到目前的工作目录。比如，如果我们的下级make目录是“/home/hchen/gnu/make”，如果我们使用“make -w”来执行，那么当进入该目录时，我们会看到：

make: Entering directory `/home/hchen/gnu/make'.

而在完成下层make后离开目录时，我们会看到：

make: Leaving directory `/home/hchen/gnu/make'

当你使用“-C”参数来指定make下层Makefile时，“-w”会被自动打开的。如果参数中有“-s”（“--slient”）或是“--no-print-directory”，那么，“-w”总是失效的。

4.5 定义命令包

如果Makefile中出现一些相同命令序列，那么我们可以为这些相同的命令序列定义一个变量。定义这种命令序列的语法以“define”开始，以“endef”结束，如：

    define run-yacc
yacc $(firstword $^)
mv y.tab.c $@
endef

这里，“run-yacc”是这个命令包的名字，其不要和Makefile中的变量重名。在“define”和“endef”中的两行就是命令序列。这个命令包中的第一个命令是运行Yacc程序，因为Yacc程序总是生成“y.tab.c”的文件，所以第二行的命令就是把这个文件改改名字。还是把这个命令包放到一个示例中来看看吧。

    foo.c : foo.y
$(run-yacc)

我们可以看见，要使用这个命令包，我们就好像使用变量一样。在这个命令包的使用中，命令包“run-yacc”中的“$^”就是“foo.y”，“$@”就是“foo.c”（有关这种以“$”开头的特殊变量，我们会在后面介绍），make在执行命令包时，命令包中的每个命令会被依次独立执行。

pear_li 2009-06-01 09:35 发表评论

]]>

A.3.3. 控制输出格式

许多操纵符使我们能够改变输出的外观。有两大类的输出控制：控制数值的表示，以及控制填充符的数量和布局。

控制布尔值和格式

改变对象格式化状态的操纵符的一个例子是 boolalpha 操纵符。默认情况下，将 bool 值显示为 1 或 0，true 值显示为 1，而 false 值显示为 0。可以通过流的 boolalpha 操纵符覆盖这个格式化：

cout << "default bool values: "
          << true << " " << false
          << "\nalpha bool values: "
          << boolalpha
          << true << " " << false
          << endl;

执行时，这段程序产生下面的输出：

default bool values: 1 0
     alpha bool values: true false

一旦将 boolalpha “写”至 cout，从这个点起就改变了 cout 将怎样显示 bool 值，后续显示 bool 值的操作将用 true 或 false 进行显示。

要取消 cout 的格式状态改变，必须应用 noboolalpha：

bool bool_val;
cout << boolalpha    // sets internal state of cout
     << bool_val
     << noboolalpha; // resets internal state to default formatting

现在只改变 bool 值的格式化来显示 bool_val，并且立即将流重置为原来的状态。

指定整型值的基数

默认情况下，用十进制读写整型值。通过使用操纵符 hex、oct 和 dec，程序员可以将表示进制改为八进制、十六进制或恢复十进制（浮点值的表示不受影响）：

const int ival = 15, jval = 1024; // const, so values never change
     cout << "default: ival = " << ival
          << " jval = " << jval << endl;
     cout << "printed in octal: ival = " << oct << ival
          << " jval = " << jval << endl;
     cout << "printed in hexadecimal: ival = " << hex << ival
          << " jval = " << jval << endl;
     cout << "printed in decimal: ival = " << dec << ival
          << " jval = " << jval << endl;

编译和执行的时候，程序产生下面的输出：

default: ival = 15 jval = 1024
     printed in octal: ival = 17 jval = 2000
     printed in hexadecimal: ival = f jval = 400
     printed in decimal: ival = 15 jval = 1024

注意，像 boolalpha 一样，这些操纵符改变格式状态。它们影响紧接在后面的输出，以及所有后续的整型输出，直到通过调用另一操纵符重围格式为止。

指出输出的基数

默认情况下，显示数值的时候，不存在关于所用基数的可见记号。例如，20 是 20,还是 16 的八进制表示？按十进制模式显示数值的时候，会按我们期待的格式打印数值。如果需要打印八进制或十六进制值，可能应该也使用 showbase 操纵符。showbase 操纵符导致输出流使用的约定，与指定整型常量基数所用的相同：

• 以 0x 为前导表示十六进制。

• 以 0 为前导表示八进制。

• 没有任何前导表示十进制。

修改程序使用 showbase 如下：

const int ival = 15, jval = 1024; // const so values never change
     cout << showbase; // show base when printing integral values
     cout << "default: ival = " << ival
          << " jval = " << jval << endl;
     cout << "printed in octal: ival = " << oct << ival
          << " jval = " << jval << endl;
     cout << "printed in hexadecimal: ival = " << hex << ival
          << " jval = " << jval << endl;
     cout << "printed in decimal: ival = " << dec << ival
          << " jval = " << jval << endl;
     cout << noshowbase; // reset state of the stream

修改后的输出使得基础值到底是什么很清楚：

default: ival = 15 jval = 1024
     printed in octal: ival = 017 jval = 02000
     printed in hexadecimal: ival = 0xf jval = 0x400
     printed in decimal: ival = 15 jval = 1024

noshowbase 操纵符重置 cout，以便它不再显示整型值的表示基数。

默认情况下，十六进制值用带小写 x 的小写形式打印。可以应用 uppercase 操纵符显示 X 并将十六进制数字 a - f 显示为大写字母。

cout << uppercase << showbase << hex
          << "printed in hexadecimal: ival = " << ival
          << " jval = " << jval << endl
          << nouppercase << endl;

前面的程序产生下面的输出：

printed in hexadecimal: ival = 0XF jval = 0X400

要恢复小写，就应用 nouppercase 操纵符。

控制浮点值的格式

对于浮点值的格式化，可以控制下面三个方面：

• 精度：显示多少位数字。

• 记数法：用小数还是科学记法法显示。

• 对是整数的浮点值的小数点的处理。

默认情况下，使用六位数字的精度显示浮点值。如果值没有小数部分，则省略小数点。使用小数形式还是科学记数法显示数值取决于被显示的浮点数的值，标准库选择增强数值可读性的格式，非常大和非常小的值使用科学记数法显示，其他值使用小数形式。

指定显示精度

默认情况下，精度控制显示的数字总位数。显示的时候，将浮点值四舍五入到当前精度。因此，如果当前精度是 4，则 3.14159 成为 3.142；如果精度是 3，打印为 3.14。

通过名为 precision 的成员函数，或者通过使用 setprecision 操纵符，可以改变精度。precision 成员是重载的（第 7.8 节）：一个版本接受一个 int 值并将精度设置为那个新值，它返回先前的精度值；另一个版本不接受实参并返回当前精度值。setprecision 操纵符接受一个实参，用来设置精度。

下面的程序说明控制显示浮点值所用精度的不同方法：

// cout.precision reports current precision value
     cout << "Precision: " << cout.precision()
          << ", Value: "   << sqrt(2.0) << endl;
     // cout.precision(12) asks that 12 digits of precision to be printed
     cout.precision(12);
     cout << "Precision: " << cout.precision()
          << ", Value: "   << sqrt(2.0) << endl;
     // alternative way to set precision using setprecision manipulator
     cout << setprecision(3);
     cout << "Precision: " << cout.precision()
          << ", Value: "   << sqrt(2.0) << endl;

编译并执行后，程序产生下面的输出：

Precision: 6, Value: 1.41421
     Precision: 12, Value: 1.41421356237
     Precision: 3, Value: 1.41

这个程序调用标准库中的 sqrt 函数，可以在头文件 cmath 中找到它。sqrt 函数量重载的，可以用 float、double 或 long double 实参调用，它返回实参的平方根。

控制记数法

默认情况下，用于显示浮点值的记数法取决于数的大小：如果数很大或很小，将按科学记数法显示，否则，使用固定位数的小数。标准库选择使得数容易阅读的记数法。

如果希望强制科学记数法或固定位数小数表示，可以通过使用适当的操纵符做到这一点：scientific 操纵符将流变为使用科学记数法。像在十六进制值上显示 x 一样，也可以通过 uppercase 操纵符控制科学记数法中的 e。fixed 操纵符将流为使用固定位数小数表示。

这些操纵符改变流精度的默认含义。执行 scientific 或 fixed 之后，精度值控制小数点之后的数位。默认情况下，精度指定数字的总位数——小数点之前和之后。使用 fixed 或 scientific 命名我们能够按列对齐来显示数，这一策略保证小数点总是在相对于被显示的小数部分固定的位置。

恢复浮点值的默认记数法

与其他操纵符不同，不存在将流恢复为根据被显示值选择记数法的默认状态的操纵符，相反，我们必须调用 unsetf 成员来取消 scientific 或 fixed 所做的改变。要将流恢复为浮点值的默认处理，将名为 floatfield 的标准库定义值传给 unsetf 函数：

// reset to default handling for notation
     cout.unsetf(ostream::floatfield);

除了取消它们的效果之外，使用这些操纵符像使用任意其他操纵符一样：

cout << sqrt(2.0) << '\n' << endl;
     cout << "scientific: " << scientific << sqrt(2.0) << '\n'
          << "fixed decimal: " << fixed << sqrt(2.0) << "\n\n";
     cout << uppercase
          << "scientific: " << scientific << sqrt(2.0) << '\n'
          << "fixed decimal: " << fixed << sqrt(2.0) << endl
          << nouppercase;
     // reset to default handling for notation
     cout.unsetf(ostream::floatfield);
     cout << '\n' << sqrt(2.0) << endl;

产生如下输出：

1.41421

     scientific: 1.414214e+00
     fixed decimal: 1.414214

     scientific: 1.414214E+00
     fixed decimal: 1.414214

     1.41421

显示小数点

默认情况下，当浮点值的小数部分为 0 的时候，不显示小数点。showpoint 操纵符强制显示小数点：

cout << 10.0 << endl;        // prints 10
     cout << showpoint << 10.0    // prints 10.0000
          << noshowpoint << endl; // revert to default handling of decimal point

noshowpoint 操纵符恢复默认行为。下一个输出表达式将具有默认行为，即，如果浮点值小数部分为 0,就取消小数点。

填充输出

按栏显示数据的时候，经常很希望很好地控制数据的格式化。标准库提供下面几个操纵帮助我们实现需要的控制：

• setw，指定下一个数值或字符串的最小间隔。

• left，左对齐输出。

  right，右对齐输出。输出默认为右对齐。

• internal，控制负值的符号位置。internal 左对齐符号且右对齐值，用空格填充介于其间的空间。

• setfill，使我们能够指定填充输出时使用的另一个字符。默认情况下，值是空格。

下面程序段说明了这些操纵符：

int i = -16;
     double d = 3.14159;
     // pad first column to use minimum of 12 positions in the output
     cout << "i: " << setw(12) << i << "next col" << '\n'
          << "d: " << setw(12) << d << "next col" << '\n';
     // pad first column and left-justify all columns
     cout << left
          << "i: " << setw(12) << i << "next col" << '\n'
          << "d: " << setw(12) << d << "next col" << '\n'
          << right; // restore normal justification
     // pad first column and right-justify all columns
     cout << right
          << "i: " << setw(12) << i << "next col" << '\n'
          << "d: " << setw(12) << d << "next col" << '\n';
     // pad first column but put the padding internal to the field
     cout << internal
          << "i: " << setw(12) << i << "next col" << '\n'
          << "d: " << setw(12) << d << "next col" << '\n';
     // pad first column, using # as the pad character
     cout << setfill('#')
          << "i: " << setw(12) << i << "next col" << '\n'
          << "d: " << setw(12) << d << "next col" << '\n'
          << setfill(' '); // restore normal pad character

执行时，该程序段产生如下输出：

i:          -16next col
     d:      3.14159next col
     i: -16         next col
     d: 3.14159     next col
     i:          -16next col
     d:      3.14159next col
     i: -         16next col
     d:      3.14159next col
     i: -#########16next col
     d: #####3.14159next col

A.3.4. 控制输入格式化

默认情况下，输入操作符忽略空白（空格、制表符、换行符、进纸和回车）。对下面的循环：

while (cin >> ch)
         cout << ch;

给定输入序列

a b   c
     d

循环执行四次从字符 a 读到 d，跳过介于其间的空格、可能的制表符和换行符。该程序段的输出是：

abcd

noskipws 操纵符导致输入操作符读（而不是跳过）空白。要返回默认行为，应用 skipws 操纵符：

cin >> noskipws;      // set cin so that it reads whitespace
     while (cin >> ch)
             cout << ch;
     cin >> skipws; // reset cin to default state so that it discards whitespace

给定与前面相同的输入，该循环进行 7 次迭代，读输入中的空白以及字符。该循环产生如下输出：

a b    c
     d

A.3.5. 未格式化的输入／输出操作

迄今为止，示例程序中只使用过格式化的 IO 操作。输入和输出操作符（<< 和 >>）根据被处理数据的类型格式化所读写的数据。输入操作符忽略空白，输出操作符应用填充、精度等。

标准库还提供了丰富的支持未格式化 IO 的低级操作，这些操作使我们能够将流作为未解释的字节序列处理，而不是作为数据类型（如 char、int、string 等）的序列处理。

编译通过了，可连接怎么也不能成功。。

查了一些书才知道，模板类的定义和实现必须放在同一文件，

《c++编程思想》中说：模板类定义很特殊，由template<...>定义的任何东西都意味着编译器在当时不为它分配内存空间，它一直处于等待状态，直到被一个模板实例告知，即模板参数是由编译器来替换的。   
        为了容易使用，几乎总是在头文件中放置全部的模板声明和定义。有时，也可能为了满足特殊需要而要在独立的cpp中放置模板的实现。但大部分现在的编译器还不支持模板类的定义和实现分开

以下的函数生成一个长度为0x500（合10进制数：1280）的cryptTable[0x500]

void prepareCryptTable()

{

    unsigned long seed = 0x00100001, index1 = 0, index2 = 0, i;

    for( index1 = 0; index1 < 0x100; index1++ )

    {

        for( index2 = index1, i = 0; i < 5; i++, index2 += 0x100 )

        {

            unsigned long temp1, temp2;

            seed = (seed * 125 + 3) % 0x2AAAAB;

            temp1 = (seed & 0xFFFF) << 0x10;

            seed = (seed * 125 + 3) % 0x2AAAAB;

            temp2 = (seed & 0xFFFF);

            cryptTable[index2] = ( temp1 | temp2 );

       }

   }

以下函数计算lpszFileName 字符串的hash值，其中dwHashType 为hash的类型，在下面GetHashTablePos函数里面调用本函数，其可以取的值为0、1、2；该函数返回lpszFileName 字符串的hash值；

unsigned long HashString( char *lpszFileName, unsigned long dwHashType )

{

    unsigned char *key = (unsigned char *)lpszFileName;

unsigned long seed1 = 0x7FED7FED;

unsigned long seed2 = 0xEEEEEEEE;

    int ch;

    while( *key != 0 )

    {

        ch = toupper(*key++);

        seed1 = cryptTable[(dwHashType << 8) + ch] ^ (seed1 + seed2);

        seed2 = ch + seed1 + seed2 + (seed2 << 5) + 3;

    }

    return seed1;

typedef struct

{

    int nHashA;

    int nHashB;

    char bExists;

   ......

} SOMESTRUCTRUE;

lpszString 为要在hash表中查找的字符串；lpTable 为存储字符串hash值的hash表

int GetHashTablePos( har *lpszString, SOMESTRUCTURE *lpTable )

{

    int nHash = HashString(lpszString);

    int nHashPos = nHash % nTableSize;

    if ( lpTable[nHashPos].bExists && !strcmp( lpTable[nHashPos].pString, lpszString ) )

    {

        return nHashPos;

    }

    else

    {

        return -1;

看到此，我想大家都在想一个很严重的问题：“如果两个字符串在哈希表中对应的位置相同怎么办？”,毕竟一个数组容量是有限的，这种可能性很大。解决该问题的方法很多，我首先想到的就是用“链表”,感谢大学里学的数据结构教会了这个百试百灵的法宝，我遇到的很多算法都可以转化成链表来解决，只要在哈希表的每个入口挂一个链表，保存所有对应的字符串就OK了。事情到此似乎有了完美的结局，如果是把问题独自交给我解决，此时我可能就要开始定义数据结构然后写代码了。然而Blizzard的程序员使用的方法则是更精妙的方法。基本原理就是：他们在哈希表中不是用一个哈希值而是用三个哈希值来校验字符串。

MPQ使用文件名哈希表来跟踪内部的所有文件。但是这个表的格式与正常的哈希表有一些不同。首先，它没有使用哈希作为下标，把实际的文件名存储在表中用于验证，实际上它根本就没有存储文件名。而是使用了3种不同的哈希：一个用于哈希表的下标，两个用于验证。这两个验证哈希替代了实际文件名。

lpszString 为要在hash表中查找的字符串；lpTable 为存储字符串hash值的hash表；nTableSize 为hash表的长度；

int GetHashTablePos( char *lpszString, MPQHASHTABLE *lpTable, int nTableSize )

{

    const int HASH_OFFSET = 0, HASH_A = 1, HASH_B = 2;

    int nHash = HashString( lpszString, HASH_OFFSET );

    int nHashA = HashString( lpszString, HASH_A );

    int nHashB = HashString( lpszString, HASH_B );

    int nHashStart = nHash % nTableSize;

    int nHashPos = nHashStart;

    while ( lpTable[nHashPos].bExists )

{

/*如果仅仅是判断在该表中时候存在这个字符串，就比较这两个hash值就可以了，不用对

*结构体中的字符串进行比较。这样会加快运行的速度？减少hash表占用的空间？这种

*方法一般应用在什么场合？*/

        if ( 　 lpTable[nHashPos].nHashA == nHashA

&& lpTable[nHashPos].nHashB == nHashB )

{

return nHashPos;

}

          else

{

              nHashPos = (nHashPos + 1) % nTableSize;

}

          if (nHashPos == nHashStart)

              break;

    }

     return -1;

/*key为一个字符串，nTableLength为哈希表的长度

*该函数得到的hash值分布比较均匀*/

unsigned long getHashIndex( const char *key, int nTableLength )

{

    unsigned long nHash = 0;

    while (*key)

    {

        nHash = (nHash<<5) + nHash + *key++;

    }

    return ( nHash % nTableLength );

补充2：

17,           37,         79,         163,          331,

673,          1361,        2729,      471,        10949,       

21911,        43853,        87719,     175447,      350899,

701819,        1403641,     2807303,   5614657,   11229331,

22458671,      44917381,     89834777, 179669557, 359339171,

一、C中const的用法总结起来主要分为以下两种：

       在定义变量时使用（注意：在定义变量时使用const，一定要进行初始化操作）：

 最简单的用法，说明变量为一个常变量：

 const int a=100;
  int const b=100;

说明指针为指向常数的指针，即指针本身的值是可以改变的：

 const int *a=&b；

  int const *a=&b；

说明指针本身的值不可改变，但指向的内容可改变：
  int * const a = &b；

说明指针为指向常数的常指针,即指针本身与指针指向的内容都不可改变：

  const int * const a = &b；

说明引用为常数引用,即不能改变引用的值：

 const int &a=100。

       在定义函数时使用：

做为参数使用，说明函数体内是不能修改该参数的：

   void func(const int a)；

 void func(int const a)；

做为返回值使用，说明函数的返回值是不能被修改的：

  const int func()；

 在函数中使用const,情况与定义变量的情况基本一致： 

 int func()

{

Const int a=10；

…

}

二、C++中区别于C的const用法主要分为以下两种

              const类成员

        const类成员在对象构造期间允许被初始化并且在以后不允许被改变。const类成员和一般的const 变量有所不同。const类成员是对应于每个对象而言，它在对象构造期间被初始化，在这个对象的生存周期中不允许被改变。
       const 成员函数

const 成员函数不允许在此函数体内对此函数对应的类的所有成员变量进行修改，这样可以提高程序的健壮性。Const一般放在函数体后：

void   fun()   const。 

我总是鼓励 C/C++ 的学习者，在刚接触这个程式语言的时候，先以 console mode（DOS-like）程式为目标。换言之，不要一开始就想写 GUI 程式、想开视窗、想有眩目亮丽的画面 -- 那只是未走先飞，揠苗助长罢了。
所谓 console 程式，就是文字模式的程式，我们可以在其中好好把 C/C++ 的语言根基练好，而不会分心於其他暂无必要的 GUI 枝节上。
我一直以为，这是理所当然的事情，却也一直发现，有不少大专院校的大一 C/C++ 课程，同学们必须写个小作家、小画家、小算盘┅做为期中或期末作业。
果然世界不能大同，各人看法殊异 :)
我不但认为 C/C++ 程式开发对象初期要以 console mode 为主，我也认为，C/C++ 的程式开发环境，初期也要以 console mode 为主。换言之，不要一开始就进入整合环境（IDE）。整合环境中那麽多视窗、那麽多功能、那麽多预设值，会让程式新手眼花撩乱，无法掌握程式编译过程中一些有价值的知识与经验。
等我们对编译程序有了起码的了解，再来使用整合环境，我认为这才最好。
所以不论在 <深入浅出 MFC> 或 <多型与虚拟> 书籍中，我都会简述console mode 下的作业方式。<深入浅出 MFC> 在 p.224 列出，<多型与虚拟> 在 p.233 列出。
但仍然偶而会收到网友（不论是否上两本书的读者）的询问，询问console mode 的编译方式，或询问他们所遭遇的问题。
我再次整理这个题目。再有类似问题，我就可以整篇 mail 给发问者了。
★★ 注意：以下适合 PC 环境 ★★
●C/C++ 编译器需要的环境变数设定
古早以来，PC 上的 C 编译器，就需要两个环境变数：
LIB：这个环境变数告诉编译器说，必要的 libraries 在哪里（哪个磁碟目录下）
INCLUDE：告诉编译器说，必要的 header files 在哪里（哪个磁碟目录下）
另外，为了让我们能够在任何 working directory 都叫得到编译器，当然我们必须设定 PATH。
从古早以来，一直到现在，C/C++ 编译器都需要这三个环境变数。
●以 Visual C++ 为例
以 Visual C++ 为例，如果安装後的档案布局如下：
C:\MSDEV\VC98\BIN : 这里放有编译器 CL.EXE
C:\MSDEV\VC98\INCLUDE : 这里放有 C/C++ header files
C:\MSDEV\VC98\LIB : 这里放有 C/C++ standard libraries
那麽你可以写一个批次档如下：
set PATH=C:\MSDEV\VC98\BIN;C:\MSDEV\COMMON\MSDEV98\BIN
set INCLUDE=C:\MSDEV\VC98\INCLUDE
set LIB=C:\MSDEV\VC98\LIB
之所以需要另外设定 PATH=C:\MSDEV\COMMON\MSDEV98\BIN，是因为编译器 CL.EXE 执行时需要 MSPDB60.DLL，而它被安装於 C:\MSDEV\COMMON\MSDEV98\BIN 之中。
如果你写的程式不只是单纯的 C/C++ 程式，还用到了 MFC，一样可以在 console mode 下编译，这时候你的环境变数应该如此设定：
set PATH=C:\MSDEV\VC98\BIN;C:\MSDEV\COMMON\MSDEV98\BIN
set INCLUDE=C:\MSDEV\VC98\INCLUDE;C:\MSDEV\VC98\MFC\INCLUDE
set LIB=C:\MSDEV\VC98\LIB;C:\MSDEV\VC98\MFC\LIB
多指定了 MFC\INCLUDE 和 MFC\LIB，就可以让编译器和联结器找到 MFC 的 header files 和 libraries。如果你还需要用到 ATL，就得在 INCLUDE 环境变数中再加上 C:\MSDEV\VC98\ATL\INCLUDE。
●以 Borland C++Builder 为例
以 Borland C++Builder 为例，如果安装後的档案布局如下：
C:\BORLAND\CBuilder3\BIN : 这里放有编译器 BCC32.EXE
C:\BORLAND\CBuilder3\INCLUDE : 这里放有 C/C++ header files
C:\BORLAND\CBuilder3\LIB : 这里放有 C/C++ standard libraries
那麽你可以写一个批次档如下：
set PATH=C:\BORLAND\CBuilder3\BIN
set INCLUDE=C:\BORLAND\CBuilder3\INCLUDE
set LIB=C:\BORLAND\CBuilder3\LIB
●如何在 console 中编译 C/C++ 程式
首先，开启一个 DOS Box（DOS Prompt, DOS VM），然後在该 DOS box 中执行上述写好的批次档，完成环境变数的设定。你可以再在 DOS 提示号下键入 set 命令，看看环境变数的设定内容正确与否。
然後就可以直接在 DOS 提示号下键入编译器名称，开始编译了。如果你使用 Visual C++，就这麽做：
C:\> CL test.cpp
如果你使用 C++Builder，就这麽做：
C:\> BCC32 test.cpp
至於特殊情况下需要什麽特殊的 options，就必须自己查一下啦。只要执行 CL /? 或 BCC32（其後不加任何引数），便可看到所有的 compile options。
●编译器与联结器的关系
早期的编译过程与联结过程是分开的。换句话说我们必须做两个动作：
C:\> Cl test.cpp
C:\> LINK test.obj xxx （xxx 代表各个必要的 libraries）
或是：
C:\> BCC32 test.cpp
C:\> TLINK32 test.obj xxx （xxx 代表各个必要的 libraries）

如今的编译过程与联结过程当然还是分开的，但是我们的动作只需一个：
C:\> CL test.cpp
或是：
C:\> BCC32 test.cpp
这是因为编译器变聪明了，除非你指定 /c option（表示只编译不联结），否则它便自动为你呼叫联结器进行联结动作。过去以来颇令 programmer烦恼的「该使用哪些 libraries」的问题，编译器也有了聪明的解决方案：它将程式中用到的 library functions 记录起来，同时也录下它们所属的library 名称，於是联结器就可以从这个表格中知道要联结哪些 libraries 了。
●环境变数与 DOS VM（Virtual Machine）的关系
你可以同时开起多个 DOS Box，但是你不能够在某个 DOS Box 中执行上述批次档而在另一个 DOS VM 中享受其环境设定。
这是因为每个 DOS Box 都是一个 Virtual Machine，彼此谁也看不到谁，互不相干。
除非你在 autoexec.bat 中就设定好上述那些环境变数。这麽一来，任何一个新开启的 DOS VM 便会因为继承最原始的 DOS VM 环境，而继承了那些变数设定。
●环境空间（environment space）不足
最易造成大家困扰的，就是环境空间（environment space）不足的问题。
当你安装好 Visual C++，会在其 BIN 子目录中发现一个名为 VCVARS32.BAT 的档案。这个档案其实就是做上述的环境变数设定动作（这在 Visual C++ 安装过程的最後一个步骤有说明。哎，有多少人安装软体不看说明！）。所以，你可以在任何 DOS Box 中执行此档，取代前述我们自己的批次档。
但是通常大家都有失败的经验，得到 "Out of environment space" 的错误讯息。这是因为 VCVARS32.BAT 使用以下句法：
set INCLUDE=%MSVCDir%\ATL\INCLUDE;%MSVCDir%\INCLUDE;%MSVCDir%\MFC\INCLUDE;%INCLUDE%
set LIB=%MSVCDir%\LIB;%MSVCDir%\MFC\LIB;%LIB%
意思是把 INCLUDE 的原始设定（%INCLUDE%）再附加其他设定，并把LIB 的原始设定（%LIB%）再附加其他设定。如果原始设定已经很长，多来这麽几次，便 "Out of environment space" 啦！
做法之一是调高环境空间的大小。请在 c:\config.sys 档中加上这行：
shell=C:\COMMAND.COM C:\ /E:1024 /P
其中 /E:1024 便是表示将环境空间调为 1024 bytes。（不够？再调）
做法之二是不要使用 VCVARS32.BAT 的那种「附加」句型，改用前述我们自己的批次档。要知道，我们可能有好几个编译器环境（VC、BCB、G++ ┅），需要轮番测试我们的程式；如果使用「附加」句型，多来几次，再大的环境空间也会消磨殆尽。
方法一和方法二要双管齐下唷。
●有任何规模上的限制吗？
使用 console 模式（或称 command line 模式）来编译联结程式，程式的大小可否有任何规模上的限制？答案是没有！
它的缺点是没有工具帮你管理档案、没有预设值让你少打几个字、没有分析工具帮你整理 objects，让你浏览 objects、symbols┅。所以一旦你基本功学会了，要开始中大型程式的设计，当然以整合环境（IDE）为佳。
●不要误会
我这不是开倒车，要大家回到茹毛饮血的时代，都回头去做山顶洞人。而是我觉得，对於一位 C/C++ 初学者，整合环境（IDE）的运用恐怕带来一头雾水，不如先在 console mode 下作业。一方面多认识一些环境设定方面的常识，满好的，一方面比较方便好用，也不必写个 1000 行的小小练习还得启动 五五加农炮，一方面求知的力量可以全部放在语言的练习上头。
等有了一定的程度，再使用整合环境，就不会如坠五里雾了。

        POSIX是Portable Operating System Interface of Unix的缩写。由IEEE（Institute of Electrical and Electronic Engineering）开发，由ANSI和ISO标准化。
        POSIX的诞生和Unix的发展是密不可分的，Unix于70年代诞生于Bell lab，并于80年代向美各大高校分发V7版的源码以做研究。UC Berkeley在V7的基础上开发了BSD Unix。后来很多商业厂家意识到Unix的价值也纷纷以Bell Lab的System V或BSD为基础来开发自己的Unix，较著名的有Sun OS，AIX，VMS。由于各厂家对Unix的开发各自为政，造成了Unix的版本相当混乱，给软件的可移植性带来很大困难，对Unix的发展极为不利。为结束这种局面，IEEE开发了POSIX，POSIX在源代码级别上定义了一组最小的Unix(类Unix)操作系统接口。
        POSIX 表示可移植操作系统接口（Portable Operating System Interface ，缩写为 POSIX 是为了读音更像 UNIX）。电气和电子工程师协会（Institute of Electrical and Electronics Engineers，IEEE）最初开发 POSIX 标准，是为了提高 UNIX 环境下应用程序的可移植性。然而，POSIX 并不局限于 UNIX。许多其它的操作系统，例如 DEC OpenVMS 和 Microsoft Windows NT，都支持 POSIX 标准，尤其是 IEEE Std. 1003.1-1990（1995 年修订）或 POSIX.1，POSIX.1 提供了源代码级别的 C 语言应用编程接口（API）给操作系统的服务程序，例如读写文件。POSIX.1 已经被国际标准化组织（International Standards Organization，ISO）所接受，被命名为 ISO/IEC 9945-1:1990 标准。
        POSIX 现在已经发展成为一个非常庞大的标准族，某些部分正处在开发过程中。表 1-1 给出了 POSIX 标准的几个重要组成部分。POSIX 与 IEEE 1003 和 2003 家族的标准是可互换的。除 1003.1 之外，1003 和 2003 家族也包括在表中。

表1：标准的重要组成部分
1003.0
管理 POSIX 开放式系统环境（OSE）。IEEE 在 1995 年通过了这项标准。 ISO 的版本是 ISO/IEC 14252:1996。
1003.1
被广泛接受、用于源代码级别的可移植性标准。1003.1 提供一个操作系统的 C 语言应用编程接口（API）。IEEE 和 ISO 已经在 1990 年通过了这个标准，IEEE 在 1995 年重新修订了该标准。
1003.1b
一个用于实时编程的标准（以前的 P1003.4 或 POSIX.4）。这个标准在 1993 年被 IEEE 通过，被合并进 ISO/IEC 9945-1。
1003.1c
一个用于线程（在一个程序中当前被执行的代码段）的标准。以前是 P1993.4 或 POSIX.4 的一部分，这个标准已经在 1995 年被 IEEE 通过，归入 ISO/IEC 9945-1:1996。
1003.1g
一个关于协议独立接口的标准，该接口可以使一个应用程序通过网络与另一个应用程序通讯。 1996 年，IEEE 通过了这个标准。
1003.2
一个应用于 shell 和 工具软件的标准，它们分别是操作系统所必须提供的命令处理器和工具程序。 1992 年 IEEE 通过了这个标准。ISO 也已经通过了这个标准（ISO/IEC 9945-2:1993）。
1003.2d
改进的 1003.2 标准。
1003.5
一个相当于 1003.1 的 Ada 语言的 API。在 1992 年，IEEE 通过了这个标准。并在 1997 年对其进行了修订。ISO 也通过了该标准。
1003.5b
一个相当于 1003.1b（实时扩展）的 Ada 语言的 API。IEEE 和 ISO 都已经通过了这个标准。ISO 的标准是 ISO/IEC 14519:1999。
1003.5c
一个相当于 1003.1q（协议独立接口）的 Ada 语言的 API。在 1998 年， IEEE 通过了这个标准。ISO 也通过了这个标准。
1003.9
一个相当于 1003.1 的 FORTRAN 语言的 API。在 1992 年，IEEE 通过了这个标准，并于 1997 年对其再次确认。ISO 也已经通过了这个标准。
1003.10
一个应用于超级计算应用环境框架（Application Environment Profile，AEP）的标准。在 1995 年，IEEE 通过了这个标准。
1003.13
一个关于应用环境框架的标准，主要针对使用 POSIX 接口的实时应用程序。在 1998 年，IEEE 通过了这个标准。
1003.22
一个针对 POSIX 的关于安全性框架的指南。
1003.23
一个针对用户组织的指南，主要是为了指导用户开发和使用支持操作需求的开放式系统环境（OSE）框架
2003
针对指定和使用是否符合 POSIX 标准的测试方法，有关其定义、一般需求和指导方针的一个标准。在 1997 年，IEEE 通过了这个标准。
2003.1
这个标准规定了针对 1003.1 的 POSIX 测试方法的提供商要提供的一些条件。在 1992 年，IEEE 通过了这个标准。
2003.2
一个定义了被用来检查与 IEEE 1003.2（shell 和 工具 API）是否符合的测试方法的标准。在 1996 年，IEEE 通过了这个标准。

       除了 1003 和 2003 家族以外，还有几个其它的 IEEE 标准，例如 1224 和 1228，它们也提供开发可移植应用程序的 API。要想得到关于 IEEE 标准的最新信息，可以访问 IEEE 标准的主页，网址是 http://standards.ieee.org/。有关 POSIX 标准的概述信息，请访问 Web 站点 http://standards.ieee.org/reading/ieee/stad_public/description/posix/。

2. Liniux下的线程编程

        Linux系统下的多线程遵循POSIX线程接口，称为pthread。从上面的描述不难知道，POSIX线程接口是POSIX众多标准中的一个（POSIX 1003.1-2001）。

        编写Linux下的多线程程序，需要使用头文件pthread.h，连接时需要使用库libpthread.a。顺便说一下，Linux下pthread的实现是通过系统调用 clone() 来实现的。clone() 是Linux所特有的系统调用，它的使用方式类似fork，关于 clone() 的详细情况，有兴趣的读者可以去查看有关文档说明。

下面是一个 POSIX 线程的简单示例程序(thread1.c)：

#include <pthread.h>
#include <stdlib.h>
#include <unistd.h>
 void *thread_function(void *arg) ...{
  int i;
  for ( i=0; i<20; i++) ...{
    printf("Thread says hi! ");
    sleep(1);
  }
  return NULL;
}
int main(void) ...{
  pthread_t mythread;
  
  if ( pthread_create( &mythread, NULL, thread_function, NULL) ) ...{
    printf("error creating thread.");
    abort();
  }
  if ( pthread_join ( mythread, NULL ) ) ...{
    printf("error joining thread.");
    abort();
  }
  exit(0);
}

 要编译这个程序，只需先将程序存为 thread1.c，然后输入：

运行则输入：

3. Windows下POSIX线程编程

       Windows本身没有提供对POSIX的支持。但有一个叫 POSIX Threads for Win32 的开源项目给出了一个功能比较完善的Windows下pthreads API的实现。目前的最新版本是Pthreads-w32 release 2.8.0 (2006-12-22)。

       我没有测试过这个最新版本，这里只给出2.7.0版的链接：ftp://sources.redhat.com/pub/pthreads-win32/pthreads-w32-2-7-0-release.exe。

       关于该开源项目的详细介绍见：http://sources.redhat.com/pthreads-win32/。

3.1 简单使用

       上面的exe文件是一个自解压文件，解压后，Pre-built.2目录中有编译所需要的头文件（include子目录）和库文件（lib子目录）。

       一个简单的测试程序(main.cpp)：

#include <stdio.h>
#include <pthread.h>
#include <assert.h>

void* Function_t(void* Param)
...{
    printf("I am a thread!  ");
    pthread_t myid = pthread_self();
    printf("thread ID=%d ", myid);
    return NULL;
}

int main()
...{
    pthread_t pid;
    pthread_attr_t attr;
    pthread_attr_init(&attr);
    pthread_attr_setscope(&attr, PTHREAD_SCOPE_PROCESS);
    pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_DETACHED);
    pthread_create(&pid, &attr, Function_t, NULL);
    printf("======================================== ");
    getchar();
    pthread_attr_destroy(&attr);
    return 1;
} 

使用 cl.exe 编译（不熟悉 cl.exe 的请参考：http://blog.csdn.net/liuyongjin1984/archive/2008/01/07/2029405.aspx 或者参见下面3.2部分）：

》rem cl.bat

》cl.exe main.cpp  /c  /I"c:pthreads-w32-2-7-0-releasePre-built.2include"

》link.exe  /out:main_cl.exe  main.obj  /LIBPATH:"c:pthreads-w32-2-7-0-releasePre-built.2lib"   pthreadVC2.lib

 3.2 使用VC++ 6.0或Visual Studio 2005来运行上面的程序

关键有两点：

1. 是将头文件（include子目录）和库文件（lib子目录）中的内容添加到VC++ 6.0或Visual Studio 2005开发环境对应的include和lib目录下。

具体来说（以添加include目录为例，添加lib目录类似）：

图1：VC++ 6.0（添加include目录：工具--》选项--》目录）

图2：Visual Studio 2005(添加include目录：tools--》options)

2. 指定link时要连接的库的名称（pthreadVC2.lib）

图3：VC++ 6.0（工程--》设置--》连接）

图4：Visual Studio 2005(project-->* property pages)

4. 书籍推荐
<< POSIX Multithread Programming Primer >>: http://download.csdn.net/source/237125

对象池的用途在这里就不介绍了，本例中只是其一个简单的实现。

#include <list>

#include <iostream>
using namespace std;

template<class T>
class object_pool
{
    list<void *> data_list;
public:
    void* malloc_data()
    {
        if(!data_list.empty())
        {
            list<void *>::iterator it = data_list.begin();
            void *p = *it;
            data_list.pop_front();
            return p;
        }
        else
        {
            void* p = malloc(sizeof(T));
            return p;
        }
    }

    void free_data(void* p)
    {
        data_list.push_back(p);
    }
};

class A
{
public:
    int value;
    A(int a):value(a){cout<<"A("<<a<<") called"<<endl;}
    ~A() {cout<<"~A("<<value<<") called"<<endl;}

    static object_pool<A> pool_;
    void* operator new (size_t size)
    {
        return pool_.malloc_data();
    }

    void operator delete(void* p)
    {
        pool_.free_data(p);
    }

};

object_pool<A> A::pool_;

void main()
{
    
    A* a1=new A(1);
    delete a1;
    
    A* a2=new A(2);
    delete a2;
}

由于种种原因，我们无法保证所有通过new在heap中申请的内存资源都安全地得到释放，例如：

class base{...};
void f()
{
   base* ptr = new base;
   ...
   delete ptr;
}


这样一系列操作中，在"..."中可能会抛出异常，最终导致delete无法得到执行，于是就造成了内存泄露。尽管我们可以设法避免在"..."中抛出异常，但是，对于后来维护和修改这段代码了人员来说，很可能加入一些控制流，从而过早地从函数从中返回，内存泄露再次发生。

一种解决之道就是，将资源封装在一个类中，利用类的析构函数来释放该资源，这样一来，无论是何种方式退出f()函数的作用域，类的析构函数总是会被调用，从而有效地避免了资源泄露。

auto_ptr就是这种方法的一种典型应用。它被称为智能指针，是一个模板类。声明一个只能指针的方法是：auto_ptr ptr(new T);为了说明auto_ptr的用法，下面是一个具体的例子：

#include <iostream>
#include <memory>      //为了使用auto_ptr你必须包含头文件:#include <memory>
using namespace std;

class demo
{
public:
  demo ()
  {
    cout << "demo()" << endl;
  }
   ~demo ()
  {
    cout << "~demo()" << endl;
  }
};
void
test_org ()
{
  cout << "test_org():" << endl;
  demo *ptr = new demo;
  return;
}

void
test_auto ()
{
  cout << "test_auto():" << endl;
  auto_ptr < demo > ptr (new demo);
  return;
}

int
main (int narg, char **arg)
{
  test_org ();
  test_auto ();
  return 0;
}


linux下，g++编译器的输出结果如下：
~$ g++ test.cpp -o test
~$ ./test
test_org():
demo()
test_auto():
demo()
~demo()

使用标准C++的类型转换符：static_cast、dynamic_cast、reinterpret_cast、和const_cast。

3.1 static_cast
用法：static_cast < type-id > ( expression )     
该运算符把expression转换为type-id类型，但没有运行时类型检查来保证转换的安全性。它主要有如下几种用法：
①用于类层次结构中基类和子类之间指针或引用的转换。
　　进行上行转换（把子类的指针或引用转换成基类表示）是安全的；
　　进行下行转换（把基类指针或引用转换成子类表示）时，由于没有动态类型检查，所以是不安全的。
②用于基本数据类型之间的转换，如把int转换成char，把int转换成enum。这种转换的安全性也要开发人员来保证。
③把空指针转换成目标类型的空指针。
④把任何类型的表达式转换成void类型。

注意：static_cast不能转换掉expression的const、volitale、或者__unaligned属性。

3.2 dynamic_cast
用法：dynamic_cast < type-id > ( expression )
该运算符把expression转换成type-id类型的对象。Type-id必须是类的指针、类的引用或者void *；
如果type-id是类指针类型，那么expression也必须是一个指针，如果type-id是一个引用，那么expression也必须是一个引用。

dynamic_cast主要用于类层次间的上行转换和下行转换，还可以用于类之间的交叉转换。
在类层次间进行上行转换时，dynamic_cast和static_cast的效果是一样的；
在进行下行转换时，dynamic_cast具有类型检查的功能，比static_cast更安全。
class B{
public:
       int m_iNum;
       virtual void foo();
};

class D:public B{
    public:
       char *m_szName[100];
};

void func(B *pb){
    D *pd1 = static_cast<D *>(pb);
    D *pd2 = dynamic_cast<D *>(pb);
}

在上面的代码段中，如果pb指向一个D类型的对象，pd1和pd2是一样的，并且对这两个指针执行D类型的任何操作都是安全的；
但是，如果pb指向的是一个B类型的对象，那么pd1将是一个指向该对象的指针，对它进行D类型的操作将是不安全的（如访问m_szName），
而pd2将是一个空指针。

另外要注意：B要有虚函数，否则会编译出错；static_cast则没有这个限制。
这是由于运行时类型检查需要运行时类型信息，而这个信息存储在类的虚函数表（
关于虚函数表的概念，详细可见<Inside c++ object model>）中，只有定义了虚函数的类才有虚函数表，
没有定义虚函数的类是没有虚函数表的。

另外，dynamic_cast还支持交叉转换（cross cast）。如下代码所示。
class A{
public:
        int m_iNum;
        virtual void f(){}
};

class B:public A{
};

class D:public A{
};

void foo(){
    B *pb = new B;
    pb->m_iNum = 100;

    D *pd1 = static_cast<D *>(pb);    //compile error
    D *pd2 = dynamic_cast<D *>(pb);  //pd2 is NULL
    delete pb;
}

在函数foo中，使用static_cast进行转换是不被允许的，将在编译时出错；而使用 dynamic_cast的转换则是允许的，结果是空指针。

3.3 reinpreter_cast
用法：reinpreter_cast<type-id> (expression)
type-id必须是一个指针、引用、算术类型、函数指针或者成员指针。
它可以把一个指针转换成一个整数，也可以把一个整数转换成一个指针（先把一个指针转换成一个整数，
在把该整数转换成原类型的指针，还可以得到原先的指针值）。

该运算符的用法比较多。

3.4 const_cast
用法：const_cast<type_id> (expression)
该运算符用来修改类型的const或volatile属性。除了const 或volatile修饰之外， type_id和expression的类型是一样的。
常量指针被转化成非常量指针，并且仍然指向原来的对象；
常量引用被转换成非常量引用，并且仍然指向原来的对象；常量对象被转换成非常量对象。

Voiatile和const类试。举如下一例：
class B{
public:
     int m_iNum;
}
void foo(){
 const B b1;
 b1.m_iNum = 100;            //comile error
 B b2 = const_cast<B>(b1);
 b2. m_iNum = 200;           //fine
}
上面的代码编译时会报错，因为b1是一个常量对象，不能对它进行改变；
使用const_cast把它转换成一个常量对象，就可以对它的数据成员任意改变。注意：b1和b2是两个不同的对象。