C++博客-酱坛子

最近做地图遇到Z-buffer精度问题

@王一伟 — Fri, 27 Mar 2009 03:31:00 GMT

关于深度冲突(Z-Finghting or Depth Fighting)的解决

        OpenGL,或者D3D 的深度缓存都存在精度问题,在最新的Nvidia GF8 系列显卡中已经开始应用float point depth buffer. 而在此之间,深度缓存其实只有位平面的概念. 这随API的不同,都需要指定后缓存深度缓存精度, Depth ,我一般使用24位,也就是D3D中常见的 D24S8. 但除非你是用浮点,否则都会有精度损失的问题,这种情况总是发生在2个几乎共面的片面,他们投影在后裁减平面时都会被赋予一个深度(当然,如果深度缓存可写的话),而上面已经说过,目前来说,深度只是位平面, 你可以把他假设为这样的形势

depth              w
0                  [near_clip,              near_clip + 0.1]
1                 [near_clip + 0.1,       near_clip +0.2]
2                 [near_clip + 0.3 ,       near_clip +0.4]
........
max             [far_clip - 0.1,                far_clip]
上面假设硬件的最小深度单元 r = 0.1

那么将会出现这样的问题.
当2个片元距离近裁减平面 w 落在同一个区间的时候,他们的深度是相等的. 最终你所看到的结果,就是下面的这种样子:

注意到蓝色线框里面.

要解决这个问题, 你只要google 或者去 beyond3d,等论坛,搜索 depth fighting ,得到的答案往往就是设置深度偏移. OpenGL : Polygon offset. D3D: Depth Bais.
拿OpenGL 来说,就是对有存在深度冲突的2个 Mesh Object A,B如下方式渲染.

A.Render();
glEnable(GL_POLYGON_OFFSET_FILL);
glPolygonOffset(0.0f,-1.0f);
B.Render();
glDisable(GL_POLYGON_OFFSET_FILL);

这是一个不错的方法,但是实际操作起来很麻烦,而且没有效率. 注意到,你必须一先一后的渲染这2个对象, 拿上图来说,我需要在MAX 中把手套和手臂脱离,形成一个独立的节点,然后我起码需要新建立2个顶点缓存,并在渲染的过程中设置2次.这对于带宽是个不小的代价.所以我不是很赞成这样去处理,当然,有的时候无法避免了,也会如此..

       如果避免发生Z-Fighting 才是关键. 注意到上面的depth - w 的位平面对应关系. 由于硬件都只能支持一定的深度格式,也就是说,Depth bits 是一定的,假为 D.而顶点的投影深度则毫无限制,他可以是 near_clip ---> far_clip 的任意一个浮点数.因此
      dw/D = (far_clip - near_clip)/near_clip;
    从上面可以看出, 要想dw 更精确,那么 near_clip 必然要更大(适用范围是far_clip >> near_clip).
上面那张存在depth-fighting 的截图当时的情况是 near_clip :0.0001 far_clip : 64000.0
下面的是在near_clip 0.1 far_clip 不变.

继续提高定点投影深度,也不会出现难看的深度冲突了.

@王一伟 2009-03-27 11:31 发表评论

实时3D绘图的阴影效果

@王一伟 — Fri, 27 Mar 2009 03:11:00 GMT

对作者心血表示感谢，先附上原文：http://www.86vr.com/teach/cursor/200410/3841.html

实时3D绘图的阴影效果

　　1 平面阴影
　　2 体积阴影

附带的源程序（91KB）

　　在目前的实时3D绘图中，要做出真实的阴影效果，是很不容易的。因为阴影是因物体遮住光源所产生的，因此，要做出正确的阴影效果，就需要对整个场景做处理，这样才能判断出哪些物体被哪些物体遮住了。

　　不过，目前的3D硬件，并不容易进行这类的测试，因为资料量和工作量都太大了。不过，这并不表示使用现在的3D硬件就无法做出阴影。现在已经有很多方法是适合用在目前的3D硬件上面，可以产生效果不错的阴影。本文会就一些常用的方法，做简单的介绍。

1、平面阴影

　　目前常用的方法，几乎都是把阴影看成是“物体投射到其它表面”来处理。在光源是平行光的时候（例如，太阳光），可以看成是物体把阴影“投射”到另一个表面上，如下图所示：

　　如果场景中只有一个重要的光源（即最强的光源），那可以假设只有这个光源会产生明显的阴影。以平行光源来说，要把阴影“投射”到一个平面上，就是一件相当容易的事。

　　设空间有一点V，平行光源的方向是L，要投射阴影的平面是P，那么，存在一常数k使

　　成立，如下图（V、L、和 P均为四维向量，表示一个三维的齐次坐标：homogeneous coordinate）：

　　解上式得

　　空间中的点V投影到平面P的位置是V+kP。对一个3D模型（model）的每个顶点都代入这个式子，就可以得到投影的结果了。不过，因为目前的3D硬件都是以4×4的矩阵来做变换，所以如果能把投影的动作写成一个矩阵，就会方便很多。

　　设V = ，L = ，P = ；展开前面的式子，会发现k有一个分母：

　　因此这个式子会有点复杂。不过，因为在OpenGL中的向量都是齐次坐标（homogeneous coordinate），所以可以先把分母提出来，放到w中。对Vx展开得到：

整理一下得到

　　这样就变成向量内积的形式，可以放到矩阵中。对Vy和Vz做同样的动作，再加上放到w的分母部分，就可以得到下面的矩阵：

　　因此，理论上，要画阴影时，把MODELVIEW矩阵设成上面的矩阵，画出物体，就会是阴影的样子。

　　上面讨论的是以平行光源为主。如果光源是点光源，也可以用类似的方法来做。

　　这个方法可以对任何平面做出阴影的效果。如果有多个平面，可以分别对每个平面都做一次。不过，这个方法显然是没办法把阴影投影到曲面上。所以，这个方法通常称为平面阴影（planar shadow）。

　　理论的部分已经讨论完了。不过，实作的时候，还有一些细节部分是需要特别注意的。

　　首先，如果真的直接用上面的方法来做，那做出来的结果可能会像这样：

　　这是因为画了图中的地板之后，再画黑色的阴影时，会和地板产生所谓的Z fighting现象，也就是阴影的一部分的Z值较地板的Z值小，所以会画出来，但是有些部分的Z值则可能比地板的Z值大，所以就没画出来了。这种现象会使得阴影变得破碎不完整。

　　现在的3D硬件通常提供一个叫多边形偏移（polygon offset）的功能，用来解决Z fighting的问题。多边形偏移的原理，是在画一个物体时，要求把它的Z值进行一个小的调整。例如，在上面的例子中，我们可以把阴影的Z值减一个小的数字，这样就可以避免Z fighting的现象。

　　处理掉Z fighting后，再来是第二个问题：

　　上图中，阴影跑到地板的外面去了。这里需要一个方法，把阴影切到地板的范围内。这个例子中，地板的边界是直线，所以可以用user defined clip planes来做。不过，如果地板是奇怪的形状，就需要别的方法。

　　而且，光是把阴影切到地板的范围内是不够的。通常阴影是用blending的方式画上去的。如果一个物体的形状比较复杂，那有些地方可能会blend两次或更多次。这样会让阴影看起来不是同一个颜色，即有些地方颜色较深而有些地方较浅。

　　现在的3D硬件多半支持模板缓冲区（stencil buffer）。模板缓冲区是一个用来“做记号”的缓冲区。通常模板缓冲区可以存放1 bits到8 bits不等的数字，不同的硬件支持的大小会不一样。目前的3D硬件通常把模板缓冲区和Z buffer放在一起。例如，它可能支持15 bits的Z buffer加上1 bit的模板缓冲区；或是支持24 bits的Z buffer加上8 bit的模板缓冲区。因此，通常模板缓冲区的测试是和Z测试一起做的，也就是在使用Z buffer时，模板缓冲区可说是“免费”的。

　　在我们的例子中，可以先把模板缓冲区（stencil buffer）全清为0。在画地板之前，把模板缓冲区设定为“当Z测试通过时，把模板的值设为1”。这样一来，画完地板之后，地板所占有的那些像素的模板值就都会是1，其它的地方还是0。现在，把模板缓冲区设定成“当Z测试通过时，若模板的值为1才画，且将模板的值设为0”。然后开始画阴影。这样画出来的阴影，一定会在地板的范围内，而且每个像素只会被画一次，不会出现blend两次的情形。

　　如果有多个平面要投影，可以为每个平面指定不同的模板（stencil）值。不过，如果模板缓冲区（stencil buffer）只有1 bit，那就没办法了。这时，可能就需要在画下一个平面之前，先把模板缓冲区清掉，这样会花很多时间。

　　下图是一个完整的例子：

　　参考程序你可以去试验。这个程序需要至少2 bits的模板缓冲区（stencil buffer）支持。

　　平面阴影（Planar shadow）就差不多是这个样子了。平面阴影的好处是简单、容易做，而且在投影面不多的时候，速度很快。但是，当投影面变多时，或是物体很复杂时，速度很快就会变得很慢，因为对每个平面都需要把投影的物体再画一次。而且，它只能投影在平面上，对于不规则的表面则完全没办法。

　　还有一些别的方法可以产生阴影的效果。后面还会再讨论一些产生阴影的方式，都可以投影在任何不规则的表面上。

2、体积阴影

　　前面所介绍的方法，即平面阴影（Planar shadow），只适用于平面上。但是，除了少数的情形之外，绝大多数的情形下，根本无法预测阴影会被投射在什么样的表面上。所以，我们需要自由度更高的方法。

　　在这里介绍一个较为灵活的方法，它可以将阴影投射在不规则的表面上。这个方法称为体积阴影（Volumetric Shadow）。这个方法的动点在于，它并不是利用“把物体投影到表面”的方式来产生阴影，而是去找出场景中，有哪些像素是在阴影中。也就是说，想象一个物体挡住光时，在物体的后面会形成一个大的“阴影锥”。很明显的，若一个像素在“阴影锥”之中，那它就是在阴影之中。如下图所示：

　　上图中的红色球体，在受光照后，在后方产生一个“阴影锥”，即Shadow Volume，而这个“阴影锥”和灰色平面的交集，就是阴影会出现的地方。

　　所以，基本上体积阴影（Volumetric Shadow）的原理是很简单的。不过，要真正实作又是另一回事。为了简单起见，这里先以一个简单的三角形开始。目前的3D绘图几乎都是以三角形为基础，所以从三角形开始，应该是很适当的。

　　现在，假设有一个已经绘制完成的3D场景。因为使用Z buffer的关系，对每一个像素而言，都有一个相对的Z值，即表示该像素和观察者的距离的值。如果现在有一个三角面，把阴影投射到这个3D场景中，并画出这个三角面的“阴影锥”。因为物体是一个三角形，所以它的“阴影锥”也是一个三角锥。这时，要如何知道3D场景中，有哪些像素是和这个三角锥有交集？

　　其实方法很简单。想象许多射线，由观察者射向每个像素。如果射线和“阴影锥”完全没有交集，它所对应的像素当然就不会和“阴影锥”有交集。不过，即使是射线和“阴影锥”有交集，并不一定表示该像素就一定和“阴影锥”有交集，因为射线可能会射入“阴影锥”后又射出。所以，只有在射线射入“阴影锥”之后，在离开“阴影锥”之前就遇到其对应的像素时，才表示这个像素和“阴影锥”有交集。下图显示出各种不同的情形：

　　上图中的（1）和（2）都是面对观察者的面，所以它们所涵盖的像素，就是“射线会射入阴影锥”的像素。而（3）则是背对观察者的面，所以它所涵盖的像素是“射线会离开阴影锥”的像素。所以，会和阴影锥有交集的像素，就是（1）+（2）-（3）的那些像素，也就是阴影所在的位置。

　　不过，要怎么在一般的3D绘图硬件中，得到（1）+（2）-（3）的结果呢？和平面阴影（Planar shadow）一样，这需要模板缓冲区（stencil buffer）。在OpenGL和Direct3D中的模板缓冲区都可以让它进行“加一”和“减一”的动作。所以，只要把模板缓冲区设定成：在绘制（1）和（2）的面时，让模板缓冲区加一；而在绘制（3）的面时，让模板缓冲区减一。这样一来，在画完（1）～（3）时，那些模板（stencil）值不为0的像素就是阴影了。最后，把所有模板不为0的像素利用alpha blending的方式，使其亮度降低，就可以达到绘制阴影的效果。

　　上面的例子是用一个三角面。对于比较复杂的物体，其原理还是一样的。当物体是由许多三角面组成时，可以把所有面对光源的三角面都进行上面的动作，就可以产生阴影。不过，这样有个缺点：因为很多三角面的边是接在一起的，所以这样做会十分浪费时间。要提高效率其实也很容易。在绘制“阴影锥”的时候，若有一个边是被两个三角面所共享，那就表示这是一个“内部”的边，在绘制“阴影锥”的时候，就可以不用去画这个边。这样就可以省下不少的时间。

　　这个方法适用于非常复杂的物体。不过，它还是可能会遇上一些问题。一个情形是，如果观察者在“阴影锥”的内部，会发生一些麻烦的情形。不过，对大部分的情形来说，只要将模板缓冲区（stencil buffer）设定成“减到0就停止”，即0 - 1 = 0，就可以解决。当然这无法解决所有的问题，不过通常已经够好了。另外，如果物体不是 convex（即“凸”的），那可能会出现“射线重复进入阴影锥”的情形。这种情形并不会有问题，不过模板缓冲区就需要比较多bit才不会出错。一般来说，4 bits就已经可以处理绝大多数的物体的。

　　下面的画面是体积阴影（Volumetric Shadow）的结果，是由DirectX 8 SDK中的一个示范程序所产生的。这个程序的结构并不复杂，所以有兴趣的话，可以自行参考它的原始码。

　　这个方法比平面阴影（Planar shadow）更能适用于不同的场景。不过，它当然也有缺点。最主要的缺点是在于它的复杂度。要做出有效率的“阴影锥”，需要对物体做相当麻烦的处理，基本上就是要找出物体在某个方向的“外缘”（即silhouette）。虽然这并不太难做，但是还是需要花费相当的CPU时间去处理。另外，为所有的物体绘制出其“阴影锥”，需要相当大量的填充率（fill rate）和内存频宽。若是延后渲染（deferred renderer），例如图素渲染（tile renderer）则影响不会这么大，特别是图素渲染可以支持一些特别的功能，来加速体积阴影（Volumetric Shadow）的动作。

　　基本上，体积阴影（Volumetric Shadow）的效果，一般来说都不错。最主要的缺点则是在效率方面，特别是当物体的复杂度和数量增加时，CPU需要的工作量会大增，是较为不理想的。后面会再介绍一些速度更快的方法。

@王一伟 2009-03-27 11:11 发表评论

内存文件映射应用举例『转』

@王一伟 — Thu, 03 Apr 2008 07:04:00 GMT

下面这些函数被应用于文件内存映射中：

1) CreateFileMapping
2) FlushViewOfFile
3) MapViewOfFile
4) MapViewOfFileEx
5) MapViewOfFileVlm
6) OpenFileMapping
7) UnmapViewOfFile
8) UnmapViewOfFileVlm

函数详细说明：『见本页末』

例子：
/*****************************************************/
/*                                                                               */
/*这个例子创建了文件映射视图，并通过这个映射     */
/*视图来操作文件内容。                                            */
/*                                                                               */
/****************************************************/
#include
#include
#include

int main()
{
HFILE hFile;
OFSTRUCT opBuf;
HANDLE hMapfile;
HANDLE hMapview;
BYTE *recv;
hFile=OpenFile(".\\map.test",&opBuf,OF_READWRITE);
if (hFile==HFILE_ERROR)
{
   printf("open file failed!\n");
   return 1;
}
hMapfile=CreateFileMapping((HANDLE)hFile,NULL,PAGE_READWRITE,0,0,"MapTest");
if(hMapfile==NULL)
{
   printf("mapping file failed!\n");
   return 1;
}
CloseHandle((HANDLE)hFile);
hFile=0;
hMapview=MapViewOfFile(hMapfile,FILE_MAP_WRITE,0,0,0);
if(hMapview==NULL)
{
   printf("mapping view failed!\n");
   return 1;
}
recv=(BYTE *)hMapview;
printf("Mapping view's content is :%.10s \n",recv);
recv[0]='s';
printf("Mapping view's content is :%.10s \n",recv);
UnmapViewOfFile(hMapview);
return 0;
}

一、CreateFileMapping 为指定文件创建一个有名或无名的文件映象；
HANDLE CreateFileMapping(
HANDLE hFile,              // 映射文件的句柄
LPSECURITY_ATTRIBUTES lpFileMappingAttributes,
                             // 安全描述符指针
DWORD flProtect,           // 对映射对象的保护
DWORD dwMaximumSizeHigh,   // 对象最大长度的高32位
DWORD dwMaximumSizeLow,    // 对象最大长度的低32位
LPCTSTR lpName             // 文件内存映射对象的名字
);

注意：
hFile：映射文件的句柄，文件的打开模式必须与flProtect参数指定的相一致；如果这个参数值为0xFFFFFFFF，那么必须在dwMaximumSizeHigh和dwMaximumSizeLow参数中指定映射对象的大小。并且将在操作系统虚拟内存页面替换文件中创建文件映射对象，而不是使用磁盘文件，同时必须给出这个映射对象的大小。文件映射对象通过副本，遗传或名字来共享。
lpFileMappingAttributes：安全描述符指针，决定返回句柄是否能被子进程继承，如果是NULL，那么子进程不能继承。WinNt中，如果是NULL，那么文件映射对象得到一个默认的安全描述符。
flProtect：为得到的文件试图指定保护模式，可以被设置为下列值：
PAGE_READONLY ：只读属性，并且hFile对应的文件必须以GENERIC_READ形式打开。
PAGE_READWRITE：可读可写属性，并且hFile对应的文件必须以GENERIC_READ 和 GENERIC_WRITE形式打开。
PAGE_WRITECOPY：对可写区域复制后操作，并且hFile对应的文件必须以GENERIC_READ 和 GENERIC_WRITE形式打开。
dwMaximumSizeHigh，dwMaximumSizeLow：如果这两个参数为0，则文件映射对象的最大长度等于hFile指定的文件长度。
lpName：文件映射对象的名字，如果这个名字已存在，则按照flProtect指定的来处理映射对象。如果此参数为空，则创建一个无名字的文件映射对象。如果此参数的名字与系统事件的名字相同，则函数执行失败，GetLastError返回 ERROR_INVALID_HANDLE；

返回值：函数调用成功返回文件映射对象的句柄，如果文件映射对象已经存在则返回原有映射对象的句柄，GetLastError返回ERROR_ALREADY_EXISTS。函数执行失败返回Null。

二、FlushViewOfFile 把文件映射视图中的修改的内容或全部写回到磁盘文件中
BOOL FlushViewOfFile(
LPCVOID lpBaseAddress, // 修改内容的起始地址
DWORD dwNumberOfBytesToFlush // 修改的字节数目
);
函数执行成功返回非零。

三、MapViewOfFile 在调用进程的地址空间映射一个文件视图
LPVOID MapViewOfFile(
HANDLE hFileMappingObject, // 已创建的文件映射对象句柄
DWORD dwDesiredAccess,      // 访问模式
DWORD dwFileOffsetHigh,     // 文件偏移的高32位
DWORD dwFileOffsetLow,      // 文件偏移的低32位
DWORD dwNumberOfBytesToMap // 映射视图的大小
);
注意：
hFileMappingObject：由CreateFileMapping 或 OpenFileMapping 返回的文件映射对象句柄。
dwDesiredAccess：映射视图的访问模式，与创建文件映射对象的保护模式flProtect有关，可以被设置为下列值：
FILE_MAP_WRITE：一个可读写属性的文件视图被创建，保护模式为PAGE_READWRITE
FILE_MAP_READ ：一个只读属性的文件视图被创建，保护模式为PAGE_READWRITE 或 PAGE_READONLY
FILE_MAP_ALL_ACCESS：与FILE_MAP_WRITE模式相同
FILE_MAP_COPY：保护模式为PAGE_WRITECOPY时，得到一个视图文件，当你对视图文件写操作时，页面自动交换，并且你所做的修改不会损坏原始数据资料。
dwNumberOfBytesToMap：映射文件部分的大小，如果为0，则映射整个文件。
返回值：
如果成功返回返回映射视图的起始地址，如果失败返回NULL。

四、MapViewOfFileEx 在调用进程的地址空间映射一个文件视图，并且允许调用进程为映射视图指定特殊的内存地址
LPVOID MapViewOfFileEx(
HANDLE hFileMappingObject, // 文件映射对象的句柄
DWORD dwDesiredAccess,      // 访问模式
DWORD dwFileOffsetHigh,     // 文件偏移的高32位
DWORD dwFileOffsetLow,      // 文件偏移的低32位
DWORD dwNumberOfBytesToMap, // 映射视图的大小
LPVOID lpBaseAddress        // 指定映射视图的其实内存地址
);
注意：
与MapViewOfFile用法相同，但是如果指定的内存地址空间大小不够，则函数执行失败。
五、OpenFileMapping 打开一个已命名的文件映射对象
HANDLE OpenFileMapping(
DWORD dwDesiredAccess, // 访问模式
BOOL bInheritHandle,    // 继承标志
LPCTSTR lpName          // 文件映射对象名指针
);
注意：
dwDesiredAccess：访问模式与MapViewOfFile中的访问模式相同。
bInheritHandle：继承标志，是否可以被一个新的进程继承使用，如果为TRUE，就可以被一个新进程继承句柄。
返回值：
成功返回一个已命名的文件映射对象，失败返回NULL。

六、UnmapViewOfFile 删除文件的映射视图
BOOL UnmapViewOfFile(
LPCVOID lpBaseAddress // 映射视图起始地址
);
注意：
lpBaseAddress：映射视图起始地址，由 MapViewOfFile 函数 MapViewOfFileEx产生。
返回值：
如果调用成功返回非零，并且所有指定地址内的脏页面会被写入硬盘。调用失败返回零。

@王一伟 2008-04-03 15:04 发表评论

#pragma once与#ifndef的区别

@王一伟 — Tue, 22 Jan 2008 10:14:00 GMT

为了避免同一个文件被include多次

1   #ifndef方式
2   #pragma once方式

在能够支持这两种方式的编译器上，二者并没有太大的区别，但是两者仍然还是有一些细微的区别。
    方式一：

    #ifndef __SOMEFILE_H__
    #define __SOMEFILE_H__
    ... ... // 一些声明语句
    #endif

方式二：

#pragma once
... ... // 一些声明语句

    #ifndef的方式依赖于宏名字不能冲突，这不光可以保证同一个文件不会被包含多次，也能保证内容完全相同的两个文件不会被不小心同时包含。当然，缺点就是如果不同头文件的宏名不小心“撞车”，可能就会导致头文件明明存在，编译器却硬说找不到声明的状况

    #pragma once则由编译器提供保证：同一个文件不会被包含多次。注意这里所说的“同一个文件”是指物理上的一个文件，而不是指内容相同的两个文件。带来的好处是，你不必再费劲想个宏名了，当然也就不会出现宏名碰撞引发的奇怪问题。对应的缺点就是如果某个头文件有多份拷贝，本方法不能保证他们不被重复包含。当然，相比宏名碰撞引发的“找不到声明”的问题，重复包含更容易被发现并修正。

   方式一由语言支持所以移植性好，方式二可以避免名字冲突。
一般可以这样处理：
#infndef XX
#define XX
    #if _MSC_VER > 1000
      #pragma once
    #endif
   .
   .
#endif
注意：   _MSC_VER 是出于版本兼容性考虑，定义
   Defines the compiler version. Defined as 1200 for Microsoft Visual C++ 6.0. Always defined.

@王一伟 2008-01-22 18:14 发表评论

在入口函数内加如该段代码能对内存泄露进行输出

@王一伟 — Fri, 21 Dec 2007 08:52:00 GMT

在入口函数内加如该段代码能对内存泄露进行输出 int tmpFlag = _CrtSetDbgFlag( _CRTDBG_REPORT_FLAG ); tmpFlag |= _CRTDBG_LEAK_CHECK_DF; _CrtSetDbgFlag( tmpFlag );

@王一伟 2007-12-21 16:52 发表评论

哈希表（摘）

@王一伟 — Thu, 13 Dec 2007 09:53:00 GMT

哈希表与哈希函数
　　哈希查找因使用哈希 (Hash) 函数而得名，哈希函数又叫散列函数，它是一种能把关键字映射成记录存贮地址的函数。
1.哈希表
①它是一种能把关键字映射成记录存贮地址的函数。
②假定数组 HT[0 ～ m-1] 为存贮记录的地址空间， m 为表长，哈希函数 H 以记录的关键字 K 为自变量，计算出对应的函数值 H(K) ，并以它作为关键字 K 所标识的记录在表 HT 中的 ( 相对 ) 地址或索引号，这样产生的记录表 HT 叫做对应于哈希函数 H 的哈希表。
③简言之，在哈希表中，关键字为 K 的记录，存贮在 HT[H(K)] 位置。
④哈希函数值 H(K) 称为 K 的哈希地址或散列地址。

3、哈希表的冲突现象
（1）冲突
    　不同的关键字值，具有相同的哈希地址，因而被映射到同一表位置上。该现象称为冲突(Collision)或碰撞。
　【例】上图中的k₂≠k₅，但h(k₂)=h(k₅)，故k₂和K₅所在的结点的存储地址相同。

（2）安全避免冲突的条件
    如何避免冲突发生，则取决于哈希函数的构造。
    使散列地址均匀地分布在哈希表的整个地址区间内，这样可以避免或减少发生冲突。
    哈希函数的构造，与关键字的长度、哈希表的大小、关键字的实际取值状况等许多因素有关，而且有的因素事前不能确定。所以，避免冲突这并非是件容易做到的事。

（3）冲突不可能完全避免
    　由于关键字的值域往往比哈希表的个数大的多，所以哈希函数是一种压缩映射，碰撞是难免的。
   【例】存贮 100 个学生记录，尽管安排 120 个地址空间，但由于学生名 ( 假设不超过 10 个英文字母 ) 的理论个数超过 2610 ，要找到一个哈希函数把 100 个任意的学生名映射成 [0 ， 119] 内的不同整数，实际上是不可能的。
   注意：问题在于一旦发生了冲突应如何处理。

构造哈希表
　　构造哈希函数的方法很多，这里只介绍一些常用的，计算简便的方法。
1.平方取中法
　　算出关键字值的平方，再取其中若干位作为哈希函数值 ( 散列地址 ) 。
【例】假定表中各关键字是由字母组成的，用二位数字的整数 01 ～ 26 表示对应的 26 个英文字母在计算机中的内部编码，则使用平方取中法计算 KEYA ， KEYB ， AKEY ， BKEY 的散列地址可得：
关键字 K     K 的内部编码            K ²           H(K)
KEYA         11052501       122157778355001      778
KEYB         11052502       122157800460004      800
AKEY         01110525       001233265775625      265
BKEY         02110525       004454315775625      315
平方之后，取左起第 7 ～ 9 位作为散列地址。

2.除留余数法
    这种方法是用模运算 (%) 得到的。设给出的关键字值为 K ，存储区单元数为 m ，则用一个小于 m 的质数 P 去除 K ，得到的余数为 R ，即： R ＝ K % P 。如果 R 落在存储区地址范围内，则 R 就取为哈希函数值 ( 散列地址 ) ；否则，再用一个线性数求出哈希函数值。
【例】有一组关键字从 000001 到 859999 ，指定的存储区地址为 1000000 ～ 1005999 ，即 m ＝ 6000 ，可选 P ＝ 599 ，若要转换关键字 K ＝ 172148 ，则有：
                R ＝ 172148 % 599 ＝ 4176
因 R 不在指定的地址范围内，所以，取哈希函数为：
                  H(K) ＝ 1000000 ＋ R
故有：
                H(K) ＝ H(172148) ＝ 1004176
这样就把关键字 K 直接转换成存储地址了。

3.数字分析法
　　对各个关键字内部代码的各个码位进行分析。假设有 n 个 d 位的关键字，使用 s 个不同的符号 ( 如，对于十进制数，每一位可能出现的符号有 10 个，即 0 、 1 、 2 、…、 9) ，这 s 个不同的符号在各位上出现的频率不一定相同，它们可能在某些位上分布比较均匀，即每一个符号出现的次数都接近 n/s 次；而在另一些位上分布不均匀。这时，选取其中分布比较均匀的某些位作为哈希函数值 ( 散列地址 ) ，所选取的位数应视存储区地址范围而定，这就是数字分析法。
注意：
　　这种方法适合于关键字值中各位字符分布为已知的情况。
例如，给定一组关键字：
K 1 ： 542482241
K 2 ： 542813678
K 3 ： 532228171
K 4 ： 542389671
K 5 ： 542541577
K 6 ： 542985376
K 7 ： 542193552

　　这里 n ＝ 7 ； d ＝ 9 ； s ＝ 10 。为了衡量各位上 s 个字符分布的均匀度，可采用度量标准：式中 a ik 表示第 i 个字符在第 k 位上出现的 (k ＝ 1 ， 2 ，…， d) 次数。λ k 值越小，可认为分布越均匀。这里，自左向右，各位上字符的分布均匀度为：
λ １＝ (7 － 7/10) 2 ＋ 9 × (0 － 7/10) 2 ＝ 44.1
λ ２＝ 44.1
λ ３＝ 44.1
λ ４＝ 7 × (1-7/10) 2 ＋ 3 × (0 － 7/10) 2 ＝ 2.1
λ ５＝ 4 × (1-7/10) 2 ＋ (3 － 7/10) 2 ＋ 5 × (0-7/10) 2 ＝ 8.1
λ ６＝ 5 × (1-7/10) 2 ＋ (2 － 7/10) 2 ＋ 4 × (0-7/10) 2 ＝ 4.1
λ ７＝ 3 × (1-7/10) 2 ＋ 2 × (2 － 7/10) 2 ＋ 5 × (0-7/10) 2 ＝ 6.1
λ ８＝ 2 × (1-7/10) 2 ＋ (5 － 7/10) 2 ＋ 7 × (0-7/10) 2 ＝ 22.1
λ ９＝ 4 × (1-7/10) 2 ＋ (3 － 7/10) 2 ＋ 5 × (0-7/10) 2 ＝ 8.1
　　假定存储区地址为 000 ～ 999 ，则应取关键字的第 4 、 6 、 7 位作为哈希函数值 ( 散列地址 ) ，它们分别为 422 、 836 、 281 、 396 、 515 、 953 和 135 。由于数字分析法需预先知道各位上字符的分布情况，这就大大限制了它的实用性。

　　构造哈希函数除了上面介绍的几种常用方法外，还有截段法，即截取关键字中的某一段数码作为哈希函数；分段迭加法，即把关键字的机内代码分成几段，再进行迭加 ( 可以是算术加，也可以是按位加 ) 得到哈希函数值。对于各种构造哈希函数的方法，很难一概而论地评价其优劣，任何一种哈希函数都应当用实际数据去测试它的均匀性，才能做出正确的判断和结论。

解决冲突的主要方法
　　虽然我们不希望发生冲突，但实际上发生冲突的可能性仍是存在的。当关键字值域远大于哈希表的长度，而且事先并不知道关键字的具体取值时。冲突就难免会发生。另外，当关键字的实际取值大于哈希表的长度时，而且表中已装满了记录，如果插入一个新记录，不仅发生冲突，而且还会发生溢出。因此，处理冲突和溢出是哈希技术中的两个重要问题。
1、开放定址法
    　用开放定址法解决冲突的做法是：当冲突发生时，使用某种探查(亦称探测)技术在散列表中形成一个探查(测)序列。沿此序列逐个单元地查找，直到找到给定的关键字，或者碰到一个开放的地址(即该地址单元为空)为止（若要插入，在探查到开放的地址，则可将待插入的新结点存人该地址单元）。查找时探查到开放的地址则表明表中无待查的关键字，即查找失败。
注意：
①用开放定址法建立散列表时，建表前须将表中所有单元(更严格地说，是指单元中存储的关键字)置空。
②空单元的表示与具体的应用相关。
    　按照形成探查序列的方法不同，可将开放定址法区分为线性探查法、线性补偿探测法、随机探测等。
（1）线性探查法(Linear Probing)
该方法的基本思想是：
　    将散列表T[0..m-1]看成是一个循环向量，若初始探查的地址为d(即h(key)=d)，则最长的探查序列为：
        d，d+l，d+2，…，m-1，0，1，…，d-1
    　即:探查时从地址d开始，首先探查T[d]，然后依次探查T[d+1]，…，直到T[m-1]，此后又循环到T[0]，T[1]，…，直到探查到T[d-1]为止。
探查过程终止于三种情况：
    　(1)若当前探查的单元为空，则表示查找失败（若是插入则将key写入其中）；
　    (2)若当前探查的单元中含有key，则查找成功，但对于插入意味着失败；
    　(3)若探查到T[d-1]时仍未发现空单元也未找到key，则无论是查找还是插入均意味着失败(此时表满)。
利用开放地址法的一般形式，线性探查法的探查序列为：
        h_i=(h(key)+i)％m 0≤i≤m-1 //即d_i=i
用线性探测法处理冲突，思路清晰，算法简单，但存在下列缺点：
　　① 处理溢出需另编程序。一般可另外设立一个溢出表，专门用来存放上述哈希表中放不下的记录。此溢出表最简单的结构是顺序表，查找方法可用顺序查找。
　　② 按上述算法建立起来的哈希表，删除工作非常困难。假如要从哈希表 HT 中删除一个记录，按理应将这个记录所在位置置为空，但我们不能这样做，而只能标上已被删除的标记，否则，将会影响以后的查找。
　　③ 线性探测法很容易产生堆聚现象。所谓堆聚现象，就是存入哈希表的记录在表中连成一片。按照线性探测法处理冲突，如果生成哈希地址的连续序列愈长 ( 即不同关键字值的哈希地址相邻在一起愈长 ) ，则当新的记录加入该表时，与这个序列发生冲突的可能性愈大。因此，哈希地址的较长连续序列比较短连续序列生长得快，这就意味着，一旦出现堆聚 ( 伴随着冲突 ) ，就将引起进一步的堆聚。

@王一伟 2007-12-13 17:53 发表评论

CL.exe的全部命令开关(摘)

@王一伟 — Mon, 26 Nov 2007 07:20:00 GMT

CL.exe的全部命令开关

/C:在预处理输出中保留注释语句
/c:只编译，不连接，相当于在"Build"菜单下选择了"Compile"
/D:定义常量和宏，与源程序里的#define 有相同效果
/E:预处理C、C＋＋源文件，将源文件中所有的预编译指令及宏展开，将注释去掉，然后将预处理器的输出拷贝至标准输出设备输出，并且在每个文件的开头和末尾加入#line
/EH:指定编译器用何种异常处理模型
/EP:同/E,只是去掉了#line
/F:设置程序的堆栈大小
/FA:设置生成何种列表文件（汇编、汇编与机器码、汇编与源码、汇编与机器码以及源码）
/Fa:指定用/FA设置的列表文件的存放路径及（或）文件名
/FD:生成文件的相互依赖信息
/Fd:设置程序数据库文件（PDB）的存放路径及（或）文件名
/Fe:设置最终可执行文件的存放路径及（或）文件名
/FI:预处理指定的头文件，与源文件中的＃include有相同效果
/Fm:创建map文件
/Fo:设置编译后Obj文件的存放路径及（或）文件名
/Fp:设置预编译文件（pch）的存放路径及（或）文件名
/FR:生成浏览信息（sbr）文件
/Fr:同/FR,不同之处在于/Fr不包括局部变量信息
/G3:为80386处理器优化代码生成
/G4:为80486处理器优化代码生成
/G5:为Pentium处理器优化代码生成
/G6:为Pentium Pro处理器优化代码生成
/GA:为Windows应用程序作优化
/GB:为Pentium处理器优化代码生成，使用80386、80486、Pentium、Pentium Pro的混合指令集，是代码生成的默认选项（程序属性选项中Processor对应Blend）
/GD:为Windows动态库（dll）作优化，此开关在VC6中没有实现
/Gd:指定使用__cdecl的函数调用规则
/Ge:激活堆栈检测
/GF:消除程序中的重复的字符串，并将她放到只读的缓冲区中
/Gf:消除程序中的重复字符串
/Gh:在每个函数的开头调用钩子（hook）函数--penter
/Gi:允许渐进编译
/Gm:允许最小化rebuild
/GR:允许运行时类型信息(Run-Time Type Infomation)
/Gr:指定使用__fastcall的函数调用规则
/Gs:控制堆栈检测所用内存大小
/GT:支持用__declspec(thread)分配的数据的fier-safety
/GX:允许同步异常处理，与/EHsc开关等价
/Gy:允许编译器将每一个函数封装成COMDATs的形式，供连接器调用
/GZ:允许在Debug build 的时候捕捉Release build的错误
/Gz:指定使用__stdcall的函数调用规则
/H:限制外部名字的长度
/HELP:列出编译器的所有的命令开关
/I:指定头文件的搜索路径
/J:将char的缺省类型从signed char改成unsigned char
/LD:创建一个动态连接库
/LDd:创建一个Debug版本的动态链接库
/link:将指定的选项传给连接器
/MD:选择多线程、DLL版本的C Run－Time库
/MDd:选择多线程、DLL、Debug版本的C Run－Time库
/ML:选择单线程版本的C Run—Time库
/MLd:选择单线程、Debug版本的C Run—Time库
/MT:选择多线程版本的C Run-Time库
/MTd:选择多线程、Debug版本的C Run—Time库
/nologo:不显示程序的版权信息
/O1:优化使产生的可执行代码最小
/O2:优化使产生的可执行代码速度最快
/Oa:指示编译器程序里没有使用别名，可以提高程序的执行速度
/Ob:控制内联（inline）函数的展开
/Od:禁止代码优化
/Og:使用全局优化
/Oi:用内部函数去代替程序里的函数调用，可以使程序运行的更快，但程序的长度变长
/Op:提高浮点数比较运算的一致性
/Os:产生尽可能小的可执行代码
/Ot:产生尽可能块的可执行代码
/Ow:指示编译器在函数体内部没有使用别名
/Ox:组合了几个优化开关，达到尽可能多的优化
/Oy:阻止调用堆栈里创建帧指针
/Q1f:对核心级的设备驱动程序生成单独的调试信息
/QI0f:对Pentium 0x0f错误指令作修正
/Qifdiv:对Pentium FDIV错误指令作修正
/P:将预处理输出写到指定文件里，文件的后缀名为I
/TC:将命令行上的所有文件都当作C源程序编译，不管后缀名是否为.c
/Tc:将指定的文件当作C源程序编译，不管后缀名是否为.c
/TP:将命令行上的所有文件都当作C＋＋源程序编译，不管后缀名是否为.cpp
/Tp:将指定文件当作C＋＋源程序编译，不管后缀名是否为.cpp
/U:去掉一个指定的前面定义的符号或常量
/u:去掉所有前面定义的符号或常量
/V:在编译的obj文件里嵌入版本号
/vd:禁止/允许构造函数置换
/vmb:选择指针的表示方法，使用这个开关，在声明指向某个类的成员的指针之前，必须先定义这个类
/vmg:选择指针的表示方法，使用这个开关，在声明指向某个类的成员的指针之前，不必先定义这个类，但要首先指定这个类是使用何种继承方法
/vmm:设置指针的表示方法为Single Inheritance and Multiple Inheritance
/vms:设置指针的表示方法为Single Inheritance
/vmv:设置指针的表示方法为Any class
/W:设置警告等级
/w:禁止所有警告
/X:阻止编译器搜索标准的include 目录
/Yc:创建预编译头文件（pch）
/Yd:在所有的obj文件里写上完全的调试信息
/Yu:在build过程中使用指定的预编译头文件
/YX:指示编译器若预编译头文件存在，则使用它，若不存在，则创建一个
/Z7:生成MSC7.0兼容的调试信息
/Za:禁止语言扩展(Microsoft Extensions to C)
/Zd:调试信息只包含外部和全局的符号信息以及行号信息
/Ze:允许语言扩展(Microsoft Extensions to C)
/Zg:为源文件里面定义的每个函数生成函数原型
/ZI:生成程序库文件（Pdb）并支持Edit and Continue调试特性
/Zi:生成程序库文件（pdb），包含类型信息和符号调试信息
/ZL:从obj文件里去掉缺省的库文件名
/Zm:设置编译器的内存分配xianzhi
/Zn:禁止浏览信息文件里面的封装
/Zp:设置结构成员在内存里面的封装格式
/Zs:快速检查语法错误
－－－－－－－－－－－－－－－－－－－－－－－－－－
vc所支持的文件类型

DSW:全称是Developer Studio Workspace，最高级别的配置文件，记录了整个工作空间的配置信息，她是一个纯文本的文件，在vc创建新项目的时候自动生成
DSP:全称是Developer Studio Project，也是一个配置文件，不过她记录的是一个项目的所有配置信息，纯文本文件
OPT：与DSW、DSP配合使用的配置文件，她记录了与机器硬件有关的信息，同一个项目在不同的机器上的opt文件内容是不同的
CLW：记录了跟ClassWizard相关的信息，如果丢失了clw文件，那么在Class View面板里就没有类信息
PLG：实际上是一个超文本文件，可以用Internet Explorer打开，记录了Build的过程，是一个日志型文件
RC：资源描述文件，记录了所有的资源信息，在资源编辑器里作的修改，实际上都是对RC文件的修改
RC2：附加的资源描述文件，不能直接资源编辑器修改，只能手工添加，可以用来添加额外的资源
RES：经过资源编辑器编译之后的资源文件，以二进制方式存放
SBR：编译器生成的浏览信息文件，在代码导航的时候非常有用，她需要在编译时指定/FR或者/Fr开关
BSC：BSCMAKE.EXE将所有的SBR文件作为输入，经过处理之后输出一个BSC文件，在代码导航的时候实际用到的是BSC文件
ILK：当选定渐增型编译连接时，连接器自动生成ILK文件，记录连接信息
PDB：全称是Program DataBase，即程序数据库文件，用来记录调试信息，是一个相当重要的文件，没有他，程序无法正常调试
LIB：如果项目输出是Dll的话，一般会输出一个跟项目同名的Lib文件，记录输出的函数信息
EXP：同Lib，是跟Dll一起生成的输出文件
PCH：全称是PreCompiled Header，就是预先编译好的头文件，在编译时指定/Yu开关时编译器自动生成

@王一伟 2007-11-26 15:20 发表评论

被误解的C++——优化variant实现(摘抄)

@王一伟 — Tue, 09 Oct 2007 14:35:00 GMT

被误解的C++——优化variant实现

所属分类：C/C++ C++ 语言
-----------------------------------------

优化variant实现
上一次，我大概制作了一个variant类型，并设法赋予这个类型同C++内置类型几乎一样的行为。但是，具体实现起来，倒是有点望而生畏。想想看，如果我的variant需要包容5种类型，那么单单一个操作符，就需要5×5+1=26个操作符重载（那单独一个是variant类型操作数的重载）。所有二元操作符都是如此。
通过蛮力来实现variant，尽管可能，但着实愚蠢。我们必须寻找更简单有效的实现途径，避免为了一个“屁眼大的”variant（请原谅我说粗话）写上几万行代码，而且这些代码就像一窝小猪仔那样相像。好在C++为我们提供了充足的现代武器，使我们拥有足够的火力摆平这些问题。
让我们先从操作数都是variant的二元操作符入手：
variant operator+( const variant& v1, const variant& v2) {…}
…
简单起见，先考察operator+的实现，然后扩展到其他操作符。
由于操作数是variant类型，那么它们可能代表不同的类型。我们必须知道操作数的实际类型，才能对其实施相应的+操作。最传统的办法就是使用switch：
variant operator+(const variant& v1, const variant& v2) {
switch(v1.get_type_code())
{
case vt_double:
switch(v2.get_type_code())
{
case vt_double:
…;
break;
…
}
case vt_int:
switch(v2.get_type_code())
{
case vt_double:
…;
break;
…
}
…
}
}
好家伙，又是一个组合爆炸。一步步来，我们先来处理这堆讨人嫌的switch…case…。一般而言，对于一个函数（操作符）内的的大量分派操作，可以使用包含函数指针的数组或者容器替代。如果标记值（这里的vt_...）是连续的，可以直接使用数组；如果标记值不连续，可以使用关联容器。这里vt_...是连续的，所以用数组比较方便：
typedef variant (*add_op_t)(const variant& v1, const variant& v2);
add_op_t tbl_type_ops[3][3];//函数指针表，假设variant对应三种类型
variant add_op_double_double(const variant& v1, const variant& v2){…}
variant add_op_double_int(const variant& v1, const variant& v2){…}
…
variant add_op_int_double(const variant& v1, const variant& v2){…}
…
tbl_type_ops [vt_double][vt_double]=add_op_double_double;
tbl_type_ops [vt_double][vt_int]=add_op_double_int;
…
variant operator+(const variant& v1, const variant& v2) {
returntbl_type_ops [v1.get_type_code()][v2.get_type_code](v1, v2);
}
operator+的代码是简单了，但是它的代码实际上转嫁到每个专用操作函数add_op_...上去了。并没有简化多少。下一步，我们来处理这些add_op_...：
template
variant add_op(const variant& v1, const variant&v2) {
throwexception(string(“cannot add type ”)+typeid(VT1).typename()
+”to”+typeid(VT2).typename());
}//主函数模板，对应不兼容类型的操作。抛出异常。
template<>
variant add_op(const variant& v1, const variant&v2) {
returnvariant(v1.dbval+v2.dbval);
}//针对double+double的操作
…
tbl_type_ops [vt_double][vt_double]=add_op;
tbl_type_ops [vt_double][vt_int]=add_op;
…
利用函数模板，及其特化，消化掉一部分的冗余代码。利用主函数模板实现所有不能互操作的类型操作，而可操作的类型则使用特化的模板实现。当然，冗余代码还是存在，这部分我们一会儿再处理。先来看看tbl_type_ops的填充。这部分代码也存在组合爆炸。为消除这个问题，我请出了模板元编程（TMP）。当然，我没有那么好的本事去直接倒腾TMP，我“借用”了boost::mpl::vector来实现这步优化：
//使用mpl::vector存放variant包容的类型
typedef boost::mpl::vectorop_types;
const int n_types=boost::mpl::size::value;
//操作函数指针表
typedef variant (*add_op_t)(const variant& v1, const variant& v2);
add_op_t tbl_type_ops[n_types][n_types];
//填充函数指针表单个元素
template
inline void set_tbl_type() {
typedefmpl::deref::type,
mpl::int_ >::type>::typetype_1;
typedefmpl::deref::type,
mpl::int_ >::type>::typetype_2;

tbl_type_ops [m][n]=add_op;
}
//填充函数指针表单元的函数对象类
template
struct fill_tbl_types_n
{
void operator()() {
set_tbl_type();//填充函数指针单元
fill_tbl_types_n()();//递归
}
};
template
struct fill_tbl_types_n//特化，递归结束
{
void operator()() {}
};
//填充函数指针表行的函数对象类
template
struct fill_tbl_types_m
{
void operator()() {
fill_tbl_types_n()();//创建并调用fill_tbl_types_n函数对象
fill_tbl_types_m()();//递归
}
};
template
struct fill_tbl_types_m<0, n>//特化，递归结束
{
void operator()() {}
};
void fill_tbl_op() {
fill_tbl_types_m()();
}
这里运用函数对象类模板的特化，构造了函数指针表的填充自动函数。在需要时，只需调用fill_tbl_op()函数即可。该函数中创建fill_tbl_types_m函数对象，然后调用。这个函数对象的operator()首先创建并调用fill_tbl_types_n函数对象。后者先调用set_tbl_type模板函数，执行填充tbl_type_op数组的[m-1, n-1]单元格。然后递归调用fill_tbl_types_n函数对象。直到n-1==0，编译器便会选择特化版本的fill_tbl_types_n函数对象。该特化的operator()操作符重载是空的，因此递归结束。这样完成一行的填充。然后，fill_tbl_types_m则递归调用fill_tbl_types_m函数对象，填充下一行。直到调用fill_tbl_types_m<0, n>特化版本，结束递归。
现在需要仔细看一下set_tbl_type<>函数模板。该模板上来就是两个typedef。这两个typedef创建了两个类型别名，分别用m和n做索引，从boost::mpl::vector中取出相应的类型：
typedefmpl::deref::type,
mpl::int_ >::type>::typetype_1;
…
头晕是吧。我的头还有点晕呢。这就是模板元编程，不停地鼓捣类型。具体的操作可以参考boost文档或《The Template Meta-programming》一书，我这里就不多说了，反正就是从一个存放类型的vector中取出所需的类型。
这样获得的两个类型用来实例化add_op<>()模板函数，并且填充到tbl_type_ops[m][n]元素中。
这样，利用TMP和GP两种强大的机制，消除了tbl_type_ops填充的组合爆炸问题。如果我们需要向variant中加入新的类型，那么只需在mpl::vector中直接加入类型即可：
typedef mpl::vectorop_types;
OK，下面回过头，来处理add_op<>中存在的组合爆炸。对于每一对可以直接或间接相加的类型，都需要做一个add_op<>的特化版本。这当然不够好。我们可以进一步抽象add_op，然后加以优化。我把整个add_op<>模板改写成如下代码：
template
variant add_op(const variant& v1, const variant& v2) {
typedeftype_ret::typeRetT;
returnvariant(v1.operator RetT()+v2.operator RetT());
}
这里，我首先利用type_ret模板（模板元函数）获得两个操作数相加后应有的返回类型。这个模板一会说明。然后，调用variant上的类型转换操作符，将两个操作数转换成返回类型。最后相加，并创建返回variant对象。代码非常简单，没法再简单了。
再来看看type_ret<>：
template
struct type_ret
{
typedefT1type;
};
template<>
struct type_ret
{
typedefdoubletype;
};
template<>
struct type_ret
{
typedefdoubletype;
};
…//其他类型对的返回类型
type_ret<>是典型的模板元函数，没有任何实际代码，只有编译时计算的typedef。主模板将第一个类型参数typedef出一个别名。其后的模板特化对于一些特殊的情况做出定义，如int和double相加返回第二个操作数类型double（即所谓的类型提升）。
我们现在已经优化了variant+varint的代码。现在来看看如何优化variant类型和其他类型的加法：
template
variant operator+(const variant& v1, const T& v2) {
returnv1+variant(v2);
}
template
variant operator+(const T& v1, const variant& v2) {
returnvariant(v1)+v2;
}
这非常简单，直接利用了variant+variant，将其它类型的操作数转换成variant类型，然后相加。

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

好，加法完成了。但还有其他操作符。每个操作符都做那么一个函数指针表，也不见得高明到哪里去。现在需要整合优化这些操作符。这里，我想到了两种方法：一种是将函数指针表和填充操作整个地封装在一个模板中，模板参数采用int op形式。每一种操作符对应一个整数（或枚举值），并利用某种手段（如singleton）唯一生成一组全局的函数表，以此处理每一种操作。另一种方法是为函数指针表加一个维度（二维扩展到三维），新的维度对应不同的操作符。前一种方法灵活性强些，而且有利于性能优化；而后一种方法实现简单。这里我使用后一种方法：
enum
{
vt_op_add=0,
vt_op_add_assign=1,
vt_op_equal=2,
vt_op_not_equal=3
…
};
const int vt_op_num=10;

template
struct var_op;

template
struct var_op
{
T operator()(const T& v1, const T& v2) {
returnv1+v1;
}
}

template
struct var_op
{
bool operator()(const T& v1, const T& v2) {
returnv1==v1;
}
}
…
template
variant variant_op(const variant& v1, const variant& v2) {
typedeftype_ret::typeRetT;
returnvariant(var_op()(v1.operator RetT()+v2.operator RetT()));
}
我使用了一个函数对象模板var_op<>抽象各种算法（二元）。针对每一种运算符特化。抽象的variant_op函数模板实例化var_op<>，然后调用。获得相应的操作。
观察variant_op的模板参数，会发现已经包含了一个操作的基本要素。（眼下这个形式正好符合逆波兰表达式）。
接下来，只需将函数指针数组，及其填充算法加以扩展，便可大功告成：
add_op_t tbl_type_ops[n_types][n_types][vt_op_num];
//填充函数指针表单个元素
template
inline void set_tbl_type() {
typedefmpl::deref::type,
mpl::int_ >::type>::typetype_1;
typedefmpl::deref::type,
mpl::int_ >::type>::typetype_2;

tbl_type_ops [m][n][op]=add_op;
}

template
struct fill_tbl_types_op
{
void operator()() {
set_tbl_type();
fill_tbl_types_op()();//递归
}
};
template
struct fill_tbl_types_op//特化，递归结束
{
void operator()(){}
}

template
struct fill_tbl_types_n
{
void operator()() {
fill_tbl_types_op();
fill_tbl_types_n()();//递归
}
};
template
struct fill_tbl_types_n//特化，递归结束
{
void operator()() {}
};

template
struct fill_tbl_types_m
{
void operator()() {
fill_tbl_types_n()();
fill_tbl_types_m()();//递归
}
};
template
struct fill_tbl_types_m<0, n, op>//特化，递归结束
{
void operator()() {}
};

void fill_tbl_op() {
fill_tbl_types_m()();
}

template
struct var_oper
{
RetT operator()(const variant& v1, const variant& v2) {
returntbl_type_ops [v1.get_type_code()][v2.get_type_code]
[op](v1, v2).operator RetT();
}
template
struct var_oper
{
variant operator()(const variant& v1, const variant& v2) {
returntbl_type_ops [v1.get_type_code()][v2.get_type_code]
[op](v1, v2);
}
于是操作符的实现，成了以下形式：
variant operator+(const variant& v1, const variant& v2) {
returnvar_oper(v1, v2);
}
bool operator==(const variant& v1, const variant& v2) {
returnvar_oper(v1, v2);
}
…
如果还觉得复杂，那么可以进一步使用宏做一些包装。
好了，variant的优化基本上完成了。当然还会有一些方面值得我们去进一步地优化，比如可以利用boost的type traits和标准库的limit优化type_ret模板的实现和类型转换操作的实现等等。这里不再赘述。
需要说明的是，整个优化仅仅针对代码，并未考虑性能问题。在优化的过程中，某些手法的使用实际上降低的性能。比如函数指针表存在间接调用，不如直接使用inline函数来的高效。而且，函数指针表要求所有指向的函数必须以相同的类型返回。为了兼容+、-等操作，我使用了值返回。但对于+=等操作符完全可以利用引用返回，以提升性能。如果要解决这种问题，需要用前面提到的模板封装函数指针表的方案，为每一个操作符创建一个函数指针表加以解决。
另一个性能问题主要是在variant与其它类型的操作中，其它类型转换成variant类型然后再计算。比起直接使用目标类型计算慢不少。这个问题也可以利用GP和TMP消除，但代码会复杂不少。
理论上，利用inline和编译器优化，可以消除大部分性能问题。但不是所有的，函数指针表的间接调用，是无论如何也优化不掉的。
此外，我在实现函数指针表的构造算法时，没有使用函数模板，而是使用了函数对象模板（重载operator()的模板）。这是因为函数模板目前不能局部特化，而这里是必须的。另一方面，由于使用了递归，函数模板无法做到inline()，而使用函数对象模板则不会有此限制。表达式fill_tbl_types_m()();最终（优化）编译后的结果会是这样（伪码）：
tbl_type_ops [2][2][0]=add_op;
tbl_type_ops [2][1][0]=add_op;
…
tbl_type_ops [1][2][0]=add_op;
…
递归和函数对象的调用没有了，完全inline化了。inline函数有时却无法做到这一点。而fill_tbl_types_op等模板实际上起到了代码生成器的作用。这也是GP的一个鲜为人知的功能。如果你有一大堆代码需要编写，而这些代码有很强的规律性和重复性，那么请优先考虑使用模板来为你生成代码，又快又好。
该总结了。如果审视一些代码，会发现只要存在重复和规律性，我们总能利用一些技术和方法加以优化，减少代码量，简化代码结构，减少潜在错误，最终提高开发效率。这里，我使用了C++的泛型编程和模板元编程技术，大幅优化了variant类型中的大量冗余代码。并且为variant类型构建了一个灵活，而又易于扩充的结构。此类技术有很广的应用，不仅仅局限在variant这种底层构件中。相关的一个应用就是构造抽象类工厂，在《Modren C++ Design》一书中，有很完整的案例。
此外，这类技术对于调和运行时多态（OOP）和编译时多态（GP）的矛盾有很大的作用。variant只有在运行时方能确定其具体的类型，而C++的模板只能提供编译时的GP。我利用函数指针数组（当然在更复杂的应用中，可以利用OOP的动多态机制），实现运行时分派操作。而利用GP和TMP大幅简化函数指针数组、操作实现函数，以及操作符的构造。这些技术和方法可以在大多数需要运行时多态，但又存在大量重复或雷同代码的地方得以应用。

@王一伟 2007-10-09 22:35 发表评论

函数指针当参数传入的写法

@王一伟 — Mon, 08 Oct 2007 03:28:00 GMT

#include
using namespace std;

int F1(int N);
int F2(int N);
int MyF(int (*pF)(int), int);

void main()
{
cout<<"函数指针调用F1，此时的结果为："< cout<<"函数指针调用F2，此时的结果为："<}

//函数F1、F2、pF的定义
int F1(int N)
{
return N*N;
}

int F2(int N)
{
return N+N;
}

int MyF(int (*pF)(int), int N)
{
return pF(N);
}

@王一伟 2007-10-08 11:28 发表评论

Assert 宏

@王一伟 — Thu, 20 Sep 2007 22:55:00 GMT

Assert 宏应该大家都知道是干什么用的吧，可能大家一般都用来检查下指针为空啊。
不过assert还有许多使用技巧的。

1.基本用法

void VectorNormalize(Vec* src, Vec* dat)
{
float length;
assert(src!=0);//检查src向量必须不为空
assert(dst!=0);//检查dst向量必须不为空

..................
..................
}

2.让assert嵌入更多的信息

void VectorNormalize(Vec* src, Vec* dst)
{
float length;
assert(src!=0 && "VectorNormalize: src vector pointer is Null");
assert(dst!=0 && "VectorNormalize: dst vector pointer is Null");

...................
...................
}
有了这个直观的字符串提示，就可以告诉当前的函数名，错误原因。

@王一伟 2007-09-21 06:55 发表评论

虚拟继承

@王一伟 — Thu, 20 Sep 2007 22:47:00 GMT

class shape {
public:
shape(int){}
};

class circle: public shape {
public:
circle(int): shape(1){}
};

class square: public shape {
public:
square(int): shape(1){}
};

class bizzare: public circle, public square {
public:
bizzare(): circle(1), square(1){}
};
这里用的就是一般的多重继承，没有虚拟继承的存在。在bizzare（之所以叫这个名字，因为……从circle和square继承而来实在是够怪异的了，呵呵）类的member initialization list中，只需要写circle和square类的构造函数就可以了，后两者再分别调用它们的基类shape（分别的两个实例）的构造函数。

而如果是虚拟继承：
class shape {
public:
shape(int){}
};

class circle: public virtual shape {
public:
circle(int): shape(1){}
};

class square: public virtual shape {
public:
square(int): shape(1){}
};

class bizzare: public circle, public square {
public:
bizzare(): circle(1), square(1), shape(1){}
};
则必须在most derived的派生类中初始化虚拟基类。

TC++PL上肯定有说的，在class hierarchy那章。

这是语言规定。因为只有一个sharp对象，从哪个基类构造都有问题（因为它们可能调用虚基类的不同构造函数，产生二义性），所以标准规定必须在most derived构造时显式或隐式（虚基类有缺省构造函数时）构造虚基类。楼主的例子里sharp没有缺省构造函数，所以必须显式构造。
TC++PL里有：
The constructor of a virtual base is invoked (implicitly or explicitly) from the constructor for the complete object (the constructor for the most derived class).

虚拟继承：发生在多重继承上，比如：一个类继承两类，但是这两个类都继承一个类。（类图出现环），即“孙子”到“爷爷”的路径超过一条时，使用，要不会有两个“爷爷”

虚函数：与继承完成多态工作。是面向对象关键中的关键。由于面向对象的设计是自顶向下的，先功能定义在实现。继承主要有实现继承和接口继承，都需要多态

@王一伟 2007-09-21 06:47 发表评论

可变参数函数设计

@王一伟 — Sun, 02 Sep 2007 04:29:00 GMT

可变参数函数设计

#include "stdafx.h"
#include <stdio.h>
#include <stdarg.h>

int mul(int num,int data1,)
{
    int total = data1;
    int arg,i;
    va_list ap;
    va_start(ap,data1);
    for(i=1;i<num;i++)
    {
        arg = va_arg(ap,int);
        total*=arg;
    }
    va_end(ap);
    return total;
}

long mul2(int i,)
{
    int *p,j;
    p = &i+1;//p指向参数列表下一个位置
    long s = *p;
    for (j=1;j<i;j++)
        s *= p[j];
    return s;
}

int main()
{
    printf("%d\n",mul(3,2,3,5));
    printf("%d\n",mul2(3,2,3,5));
    return 0;
}

printf的设计

#include "stdio.h"
#include "stdlib.h"
#include <stdarg.h>

void myprintf(char* fmt, )        //一个简单的类似于printf的实现，//参数必须都是int 类型
{
    //char* pArg=NULL;               //等价于原来的va_list
    va_list pArg;
    char c;

   // pArg = (char*) &fmt;          //注意不要写成p = fmt !!因为这里要对参数取址，而不是取值
  // pArg += sizeof(fmt);         //等价于原来的va_start
    va_start(pArg,fmt);

    do
    {
        c =*fmt;
        if (c != '%')
        {
            putchar(c);            //照原样输出字符
        }
        else
        {//按格式字符输出数据
            switch(*++fmt)
            {
            case 'd':
                printf("%d",*((int*)pArg));
                break;
            case 'x':
                printf("%#x",*((int*)pArg));
                break;
            case 'f':
                printf("%f",*((float*)pArg));
            default:
                break;
            }
            //pArg += sizeof(int);               //等价于原来的va_arg
            va_arg(pArg,int);
        }
        ++fmt;
    }while (*fmt != '\0');
    //pArg = NULL;                               //等价于va_end
    va_end(pArg);
    return;
}
int main(int argc, char* argv[])
{
    int i = 1234;
    int j = 5678;

    myprintf("the first test:i=%d",i,j);
    myprintf("the secend test:i=%f; %x;j=%d;",i,0xabcd,j);
    system("pause");
    return 0;
}

可变参数在编译器中的处理

我们知道va_start,va_arg,va_end是在stdarg.h中被定义成宏的, 由于1)硬件平台的不同 2)编译器的不同,所以定义的宏也有所不同,下面以VC++中stdarg.h里x86平台的宏定义摘录如下(’"’号表示折行):

typedef char * va_list;
#define _INTSIZEOF(n) \
((sizeof(n)+sizeof(int)-1)&~(sizeof(int) - 1) )
#define va_start(ap,v) ( ap = (va_list)&v + _INTSIZEOF(v) )
#define va_arg(ap,t) \
( *(t *)((ap += _INTSIZEOF(t)) - _INTSIZEOF(t)) )
#define va_end(ap) ( ap = (va_list)0 )

定义_INTSIZEOF(n)主要是为了某些需要内存的对齐的系统.C语言的函数是从右向左压入堆栈的,图(1)是函数的参数在堆栈中的分布位置.我们看到va_list被定义成char*,有一些平台或操作系统定义为void*.再看va_start的定义,定义为&v+_INTSIZEOF(v),而&v是固定参数在堆栈的地址,所以我们运行va_start(ap, v)以后,ap指向第一个可变参数在堆栈的地址,如图:

高地址|-----------------------------|
|函数返回地址 |
|-----------------------------|
|. |
|-----------------------------|
|第n个参数(第一个可变参数) |
|-----------------------------|<--va_start后ap指向
|第n-1个参数(最后一个固定参数)|
低地址|-----------------------------|<-- &v
图( 1 )

然后,我们用va_arg()取得类型t的可变参数值,以上例为int型为例,我们看一下va_arg取int型的返回值: j= ( *(int*)((ap += _INTSIZEOF(int))-_INTSIZEOF(int)) );
首先ap+=sizeof(int),已经指向下一个参数的地址了.然后返回ap-sizeof(int)的int*指针,这正是第一个可变参数在堆栈里的地址(图2).然后用*取得这个地址的内容(参数值)赋给j.

高地址|-----------------------------|
|函数返回地址 |
|-----------------------------|
|. |
|-----------------------------|<--va_arg后ap指向
|第n个参数(第一个可变参数) |
|-----------------------------|<--va_start后ap指向
|第n-1个参数(最后一个固定参数)|
低地址|-----------------------------|<-- &v
图( 2 )

最后要说的是va_end宏的意思,x86平台定义为ap=(char*)0;使ap不再指向堆栈,而是跟NULL一样.有些直接定义为((void*)0),这样编译器不会为va_end产生代码,例如gcc在linux的x86平台就是这样定义的.在这里大家要注意一个问题:由于参数的地址用于va_start宏,所以参数不能声明为寄存器变量或作为函数或数组类型.关于va_start, va_arg, va_end的描述就是这些了,我们要注意的是不同的操作系统和硬件平台的定义有些不同,但原理却是相似的

@王一伟 2007-09-02 12:29 发表评论

MFC RTTI的三个宏

@王一伟 — Wed, 29 Aug 2007 07:18:00 GMT

mfc的三个宏
DECLARE_DYNAMIC 支持RTTI
DECLARE_DYNCREATE 支持RTTI 类动态创建
DECLARE_SERIAL 支持RTTI 类动态创建及序列化

@王一伟 2007-08-29 15:18 发表评论

线程安全

@王一伟 — Wed, 15 Aug 2007 00:09:00 GMT

MFC对象不要跨线程使用，因为MFC不是线程安全的。比如CWnd对象不要跨线程使用,可以用窗口句柄（HWND）代替。CSocket/CAsyncSocket对象不要跨线程使用,用SOCKET句柄代替.那么到底什么是线程安全呢?什么时候需要考虑?如果程序涉及到多线程的话，就应该考虑线程安全问题。比如说设计的接口，将来需要在多线程环境中使用，或者需要跨线程使用某个对象时，这个就必须考虑了。关于线程安全也没什么权威定义。在这里我只说说我的理解：所提供的接口对于线程来说是原子操作或者多个线程之间的切换不会导致该接口的执行结果存在二义性,也就是说我们不用考虑同步的问题。

一般而言“线程安全”由多线程对共享资源的访问引起。如果调用某个接口时需要我们自己采取同步措施来保护该接口访问的共享资源,则这样的接口不是线程安全的.MFC和STL都不是线程安全的. 怎样才能设计出线程安全的类或者接口呢?如果接口中访问的数据都属于私有数据,那么这样的接口是线程安全的.或者几个接口对共享数据都是只读操作,那么这样的接口也是线程安全的.如果多个接口之间有共享数据,而且有读有写的话,如果设计者自己采取了同步措施，调用者不需要考虑数据同步问题，则这样的接口是线程安全的，否则不是线程安全的

@王一伟 2007-08-15 08:09 发表评论

_stdcall(WINAPI) 与 _cdecl的区别

@王一伟 — Tue, 14 Aug 2007 23:56:00 GMT

_stdcall是新标准C/C++函数的调用方法.从底层上说,使用这种调用方法参数的进栈顺序和标准C调用(_cdecl方法)是一样的,都是从右到左,但是_stdcall采用自动清栈的方式,而_cdecl是手工清栈.

windows规定,凡事有它来负责调用的函数必须定义为_stdcall类型.

比如回调函数.

如果没有显试声明的话,函数的调用方法默认是_cdecl.

@王一伟 2007-08-15 07:56 发表评论

EXPORTER LAB

@王一伟 — Tue, 14 Aug 2007 08:35:00 GMT

EXPORTER LAB

Overview: This lab will work through the process of creating a simple “Exporter” MAX Plug-in. The goal of the lab will be to familiarize the developer with the basics of creating a MAX plug-in, and the basics of exporting 3ds max scene data.

This lab is composed of 5 phases. At the beginning of each phase you will find a link to a .zip file that contains source code for the exporter that is relevant to the topic of that phase. Phase 0 provides the basic Microsoft Visual C++ v6 project skeleton. Each phase builds upon what was discussed in the previous ones, so simply replace and add the files in the source of the current phase to the previous ones.

Table of Contents

PHASE 0: STARTING OUT

PHASE 1 : GEOMETRY

PHASE 2 : TEXTURES AND LIGHTING

PHASE 3: ANIMATION AND MODIFIERS

PHASE 4: CUSTOM DATA

OTHER STRATEGIES, FUTURE DIRECTIONS

Legend

In order to help in identifying the various entries in this document the following legend will be applied:

MaxSDK Classes are in this format: IDerivedObject

MaxSDK Methods are in this format: DoExport()

Filenames are in this format: export.cpp

Source code that is only relevant to this tutorial are in this format: PerFaceData

PHASE 0: STARTING OUT

Source code for Phase 0: phase0.zip

We’ll start with the process of creating our own “skeleton” plug-in from scratch.

In general, when creating plug-ins, I try the following steps in the following order:

If a skeleton for the plug-in types exists, I start with that
If not, I use the AppWizard, if the wizard supports the plug-in type
Otherwise, I do the following

Create a new Win32 DLL project in MSDEV. I usually put the plug-in project under the MAXSDK directory.

I setup the project configs to build the plugin DLL, with the appropriate extension, into the MAXSDK\PLUGIN directory. I use relative paths and add ..\include to the include path and ..\lib to the lib path. I setup the C Runtime settings as appropriate (Debug Multithreaded DLL for Debug and Multithreaded DLL for Release), and create the Hybrid project configuration (by copying the Debug config, but setting the C Runtime to release-mode Multithreaded DLL)

I usually add 2 CPPs ([PLUGINNAME].CPP and DLLENTRY.CPP), the former will hold the various implementation code for the actual plugin-type derived class(es), the latter will hold the requirement C-style plugin DLL exports. Likewise, I usually add a PLUGINNAME.H that has the class definitions of the plugin-type derived class(es).

I add the appropriate [PLUGINNAME].DEF file, with the appropriate 3ds max DLL exports. The def file looks something like:

LIBRARY MyPlugIn
EXPORTS
LibDescription		@1
LibNumberClasses	@2
LibClassDesc		@3
LibVersion		@4
SECTIONS
.data READ WRITE

I add a string table to the resources, along with a version resource. If the plug-in has a dialog, I add one. For this simple exporter lab, there is no additional dialog (well, there’s the about box, which doesn’t really count).

Plug-in Requirements

I then proceed to add the basic classes that all plug-ins need. I start with coding the DLL exports, which are more or less boilerplate, into DLLENTRY.CPP. This in turn (via LibClassDesc) leads directly to the creation of the required plug-in ClassDesc.

The DLL exports are fairly self-explanatory. DLLMain (not an export per se) initializes some custom controls. LibDescription will return the localized string that describes the plugin. LibNumberClasses returns the number of plug-in type classes the plug-in DLL provides (for this example, we only provide 1). LibClassDesc returns the ClassDesc for 3ds max to use to identify and create plug-in type objects. LibVersion returns the version of MAX the plug-in works with, which is always defined in the 3ds max headers as VERSION_3DSMAX.

LibClassDesc often just returns the address of a single static ClassDesc. For this tutorial, I derived from ClassDesc2. In general, for those familiar with this process, I recommend working with ClassDesc2 and ParamBlock2 instead of their predecessors. In general, the previous versions will be phased out in the future.

As discussed earlier, the ClassDesc acts mainly as a class factory for the main derived plug-in class. In this case, the main plug-in class we will derive from SceneExport. In our plugin we declare derivations of both ClassDesc2 and SceneExport. Typically, a single static instance of the derived ClassDesc is created and returned by LibClassDesc. The derivation also returns category, class ID, and name information about our derivation of SceneExport. The SDK has a tool (GENCID.EXE) that provides an easy way to create unique Class Ids.

This brings us to the plug-in type object derivation. We provide a derivation for SceneExport in our header (MyExporter). The basic required overrides for SceneExport are briefly explained as follows:

int ExtCount() : Returns the number of file extensions that the exporter provides (for our example, we provide 1, which I arbitrarily decided would be “MEP”).
const TCHAR * Ext(int n) : Returns the 3-letter file extension string for the given extension index (0-based).
const TCHAR * LongDesc() : Provides the “long” description of the file export format.
const TCHAR * ShortDesc() : Provides the “short” description of the file export format, shown in the file export dialog drop-down.
const TCHAR * AuthorName() : Provides the string that describes the author and/or company of the exporter plugin.
const TCHAR * CopyrightMessage() : Provides the string that shows the copyright for the given exporter and/or exporter format.
const TCHAR * OtherMessage1() : not used
const TCHAR * OtherMessage2() : not used
unsigned int Version() : Somewhat redundant, but returns a version number for the exporter.
void ShowAbout() : Shows an about box, accessible by the user from the main MAX export dialog.
int DoExport() : The actual export method. BOOL SupportsOptions() : Returns TRUE if the exporter supports some custom export options. Currently, only one option (export selected versus export entire scene) exists.

Most of the methods are basic returns of localized strings from the string table, or constants/defines. The real “meat” of an exporter plugin is the DoExport method, which we’ll expand in the next sections. This example is simple and therefore has no custom exporter options. You may want to take a look at the exporter samples, and the skeleton exporter, for a simple way to provide a special “before export” dialog that has exporter-specific options.

I added some protected methods (DoHeader, DoNodes, DoTailer) in my basic plan of exporting scene-global information, followed by per-node information, followed by any “end delimiter” file information (if nececssary). I also added some cached pointer member variables, and a cached FILE pointer to open/write to during the actual export.

Note: Some of the above can be read about in more detail in a section of the SDK helpfile titled “Creating a New Plug-In Project”.
Note 2: You may note that in the SDK samples, many different styles of code organization are used. Feel free to use the style you feel most comfortable with.

Try it

Create a sub-directory off your MAXSDK directory called “Exporter”
Un-zip / Copy Phase0 project/source files into Exporter directory
Start MSDEV, and open Exporter project
Examine the Project and Build settings. Notice the extra Hybrid Build configuration. Notice the relative lib paths and the added MAX libraries, the output destination, and the C-Runtime type (Multithreaded DLL or Debug Multithreaded DLL)
Examine the project files. First, look at the EXPORTER.DEF file and notice the four DLL exports
Look at the DLLENTRY.CPP file, and examine each of the DLL exports closely, including the DLLMain. This CPP is complete, and we will not need to modify it for the remainder of the session
Look at EXPORTER.H. Notice the #define MYEXP_CLASSID , and the MyExporter declaration.
Look at EXPORTER.CPP. Notice the MyExporterClassDesc declaration and implementation. Notice the (mostly empty at this point) implementation of MyExporter.
Examine the Project resources, which at this point include a generic About Box Dialog resource, a generic Version resource, and a String Table resource.
If you have the compiler and 3ds max handy, feel free to go ahead and compile the plugin (suggested you use Hybrid Build Configuration at this point) and try using it. In 3ds max, you can either doa File->Export orFile->Export Selected (if there are objects selected), and get the File Export Dialog. In that dialog, if the plug-in is properly loaded, you should find the “*.MEP” MyExporter format. Naturally, at this point, if you export to this format, you’ll get an empty file.

PHASE 1 : GEOMETRY

Source code for Phase 1: phase1.zip

For the first actual 3ds max scene contents we export, we’ll concentrate on just the geometry of geometric scene objects.

To facilitate working with nodes in the 3ds max scene, we first need to create a node enumerator method that walks over and processes the nodes in the MAX scene. There are various ways to do this: provide our own method that walks the scene manually, or utilize IScene and TreeEnum callbacks via ExpInterface. For this example, we’ll code our own enumerator from scratch.

For some brief backgrounder information on 3ds max's Scene hierarchy, the basic layout is of a scene tree, with a single “root” Node, whose children are all the nodes in the scene. If a node has a heirarchy (via a 3ds max “link”, or perhaps based on the layout of the object, e.g. bones), this will be represented in the “tree” as well. The Schematic view gives a pretty good visual idea of what this more or less looks like.

The Root node is somewhat special, and can be accessed via the Interface::GetRootNode utility method. The Root node doesn’t represent any actual geometry or the like.

For our node walker, the basic pseudo-code looks something like:

nodeEnum(Node ptr)
If the ptr isn’t valid, exit
If the ptr isn’t selected, and we’re exporting only selected nodes, exit
If the user canceled (usually via ESC), exit
Otherwise
Evaluate the object, determine what type of object it is, and call
a specific helper method that exports that type of object
For each child of the current ptr Node
nodeEnum(child)

The code that will call the “nodeEnum” will be in MyExporter::DoNodes, and look something like:

Get a count of the children of the Root Node
For each child of the Root Node
Check for cancel and break if cancelled
nodeEnum(child)

Try it

Based on the above pseudo-code, write the given portions of code. You’ll need to look at INode ( ::Selected(), ::NumberOfChildren(), ::GetChildNode(), ::EvalWorldState()), Interface ( ::GetRootNode(), ::GetCancel()) and possibly ObjectState and Object (::SuperClassID()) in the SDK docs
Compare your code with the code snippet from Phase 1 exporter-nodeenum.cpp

ObjectState and Node::EvalWorldState are probably worth a bit more explanation. As you may already know, the 3ds max geometry pipeline maintains a “Object” that flows up the pipeline, and can essentially be represented by different, animated states, starting with a “Base” object, then possibly into a “Derived” object with a modifier, and so on.

EvalWorldState tells the node to take it’s Object “stack” and effectively make a collapsed copy, such that the resulting ObjectState contains the final end-result of the stack. This is also what is effectively used at Render time.

Note: I also added some code to MyExporter::DoHeader that exports some basic header file information (date/time created, title string, etc). Feel free to examine.

Meshes

3ds max Meshes are triangle polygonal meshes. Every geometric (renderable) object in a 3ds max scene must be able to convert itself to a triangle mesh. Anything in the scene collapsed to a editable mesh will already be in tri-mesh form, however primitives (modified or not) may not be. To get the triangle mesh, we use the Object::ConvertToType API and request a TRIOBJ_CLASS_ID.

When calling ConvertToType, it’s important to check the returned result pointer, and see if it’s the same as the original Object pointer. If so, this implies the Object didn’t generate any new stuff, and thus we shouldn’t delete the result. Otherwise, the Object did generate a new mesh, and we, the caller, are responsible for freeing the mesh.

Once we have a mesh, we extract and dump out the number of vertices and number of faces. This information is available as APIs off the Mesh class.

As the mesh data is in Object Space, we need to get the Node Transform Matrix (for the current frame). We export this first in generic row-major format.

We then export the world-space point of each mesh vertex, multiplying the vertices by the object TM.

We then export the faces, described by three indices into the vertex array. The vertices, taken in counter-clockwise order, describe the “front” (positive normal) of the face. We also export the “edge visibility”, which describes, for a given edgeA->B, if 3ds max draws a highlight line in the viewport or not, and also if in edit-mesh-edge mode, if the edge can be selected. Finally, we export the smoothing group for each face, which could be used with the vertex normals (which we don’t export for now, left as an exercise) to smooth the mesh via Phong or other shading method.

For this phase, we do not export any mesh material or UV information. This will be done in Phase 2.

Try it

In the last part, we had nodeEnum call a utility method to export GeomObjects (in the code sample this is MyExporter::ExportGeomObject). Try implementing ExportGeomObject to export the Node Transform Matrix, and if the Node can convert itself to a TriObject, try exporting the Mesh information. You’ll need to look at Inode::GetNodeTM() and the Matrix3/Point3 classes in the SDK docs for getting the matrix information. You’ll need to look at the Object::ConvertToType() and TriObject and Mesh class in the docs for exporting the mesh information.
Compare the code with the code fragment exporter-geom.cpp. The code fragment has both the mesh and the patch (next) exporter code – the mesh exporter code is the second “chunk” in ExportGeomObject.

Patches

For patches, we provide an additional code path in ExportGeomObject that looks for PATCHOBJ_CLASS_ID and exports the patch information. Patches in the 3ds max scene can be patch grids, or any object converted to an editable patch.

As with Meshes, we use ConvertToType to get the PatchObject out. The PatchObject will contain the PatchMesh object, which contains all the overall geometric information (total verts, vectors, edges). We export all the information for both triangular and quad patches. Note that a PatchMesh can contain a collection of actual tri/quad patches, described by indices into the various overall PatchVert/PatchVec/PatchEdge arrays.

Patches can be either TriPatch or QuadPatch, defined by either 3 or 4 bezier edge splines. 3ds max uses bicubic (degree 3, with effectively 4 “control” points) patches. It does something fairly tricky when connecting Tri and Quad patches together, which is to internally promote Tri patches to quadric (degree 4) to get good continuity between patches.

How you interpolate your patch geometry is up to you – the process 3ds max uses is somewhat beyond the scope of this tutorial, but this is documented in the SDK helpfile.

For this tutorial, we’re done with basic geometry information. There are various other geometric things that could be exported – for example, we could export NURBs data, Shapes (splines and the like), or export primitive information for game engines that have built in basic primitive support.

Try it

Try writing the code to export out the PatchObject information, added in a separate method or to the body of ExportGeomObject (I did the latter). You’ll need to examine PatchObject, PatchMesh, and Patch classes in the SDK docs.
Examine and compare to exporter-geom.cpp
Finally, compile and build the plug-in, and try exporting some scenes in 3ds max with either mesh or patch objects.

PHASE 2 : TEXTURES AND LIGHTING

Source code for Phase 2: phase2.zip

Textures

First, we need to actually export the materials used in the 3ds max scene. This is part of our “header” or global information.

We iterate over the list of Material used in the 3ds max scene via the Interface::GetSceneMtls() API. For each mtl, for this tutorial, we just print out basic name information. If the mtl has subtexmaps, we print out one-level deep information on the legal subtexmaps. Also, for the purposes of an example, if the subtexmap happens to be a Bitmap Texmap, we print out the filename of the bitmap.

Try it

Update DoHeader by exporting information about the Scene Materials, using the guidelines above.
Compare to exporter-scenemtls.cpp

Texture Vertices in Meshes

For meshes, we first add to the section of code that exports mesh Face information, and append the face’s Material ID number to the list of face information. This is specifically for multi-materials. Note that the ID is usually set up in advance by the user. Note also that the MatID should be mod’d by the number of submats in a multi-mat.

We then need to get the texture vertices out of the mesh. Each mesh can support up to 99 different texture “channels”, each channel having a different UVW mapping. The mapping information is contained in the texture vertices. Note that typically, the default UVW mapping is contained in map channel #1. Map channel #0 is usually reserved for color-per-vertex info, and for this tutorial, we will not export this information. Channels 2-99 can be used for almost any other purpose, but we’ll treat them the same as channel 1 for this exporter.

Each Mesh face has a corresponding Texture Face. The Texture Faces contained in the Mesh have the corresponding three texture vertices that make up that “face”. Note that each texture face can have different associated texture vertices, so there is not a one-to-one mapping between mesh vertices and mesh texture vertices (thankfully).

Texture Vertices in Patches

For patches, getting texture vertex information is actually similar to what we did for meshes – the APIs of PatchMesh are slightly different, but pretty close.

Each Patch within a PatchMesh should have a corresponding TVPatch, which in turn contains 4 (and always 4) corresponding texture vertex indices. This is similar to a TVFace in the Mesh class.

Try it

For this step, the example code is somewhat embedded in the routine, so it’s easier to just look at the relevant portions of updated code in ExportGeomObject in exporter.cpp in phase2. Pay attention to the three portions which are:

Exporting the basic node material name (and wire color, if no material was assigned)
Exporting the texture vertices information for the texture channels for patches
Exporting the texture vertices information for the texture channels for meshes

Lighting

For most engines/export formats, lighting data is just as important as material information. As such, we add the ability to export basic light information in our exporter.

We first add information about the color of the ambient light in the scene in the exporter header. We simply pull the Ambient light color at the current frame using Interface::GetAmbient.

We add another helper method ExportLightObject and a check for LIGHT_CLASS_ID in our node enumerator. In ExportLightObject, we extract the GenLight and LightState information from the evaluated (via GenLight::EvalLightState) object. Note that for this sample, we ignore the fact that many aspects of the light could be animated.

For this tutorial, we export the light type, the intensity and color, the TM of the light, and the TM of the target (if the light happens to have a target, like a targeted spot or directional light), and some basic shadow information. There are various other things that can be exported, including the exclusion list of objects the light affects and ignores. For simplicity, we don’t export this info, but see GenLight and LightState for more details.

Try it

Try adding code to export the global ambient light as described above to DoHeader.
Try updating nodeEnum to call a separate newly added method ExportLightObject.
Try implementing ExportLightObject as described above.
Compare with exporter-lights.cpp

PHASE 3: ANIMATION AND MODIFIERS

Source code for Phase 3: phase3.zip

We’ve managed to export a lot of “static” information in our exporter, but it’s now worth taking a quick look at exporting some of the more dynamic information in a 3ds max scene, including keyframe animation information, pipeline modifier information, and things like IK information.

The first thing we do is introduce the concept of frames of animation by adding basic number-of-frames info to our export file header – start and end frame numbers (thereby also exporting the number of frames), and the frame rate in seconds. This information is easily accessible via the Interface pointer.

As mentioned previously, there’s a number of things related to lights that can be animated, that we won’t export for simplicity.

Try it

Update DoHeader and export the number of frames in the scene animation as described above. You’ll need to read about the TimeValue and Interval classes, and utilize Interface::GetAnimRange(), GetTicksPerFrame() and possibly GetFrameRate().
Compare with the changes made to DoHeader in exporter.cpp in phase 3 (made at the end of the routine).

Accessing Modifiers

There may be some instances where you may need to extract modifier information on a particular scene object. One popular example is exporting information from the 3ds max R4.x “Skin” modifier.

Keeping things simple, we just want to export the “Bend” modifier data if found. To access the modifiers (if any) for a given scene node, we need to work with the “unevaluated” pipeline. That is, we want to access the derived or base objects within the pipeline without looking at the “final” world state object.

This is relatively simple. Given a node, we can look at the existing ObjectRef via INode::GetObjectRef(). If this Object is a Derived Object (super class ID is GEN_DERIVOB_CLASS_ID), then there exist modifiers in the pipeline. We can cast the Object as an IDerivedObject and iterate over the modifiers associated with the derived object in the pipeline.

The one trick with this is being able to access the given Modifier derived class once it is found (via looking for a given modifier class ID). For this example, as the Bend modifier is part of the collection of default 3ds max modifiers, we cut-n-paste the class definition of BendMod from BEND.CPP, and tweak some of the inline definitions to compile in our project. Clearly, there are a lot of problems with this – if we were to use any of the actual BendMod methods, we would have to link with the modifier properly, and have some sort of shared header, etc. This is what a number of “public” modifiers do (e.g. Physique, Morpher Modifier, COMSkin). Definitely take a look at the “MorpherView” sample in the SDK that uses an exported Morpher modifier API.

The other thing to consider when working with modifiers is that they could potentially store node-specific data separately from the modifier instance. This is often due to a single modifier being instanced for multiple nodes (e.g. single bend modifier applied to multiple selected objects with use-pivots unchecked results in a single “bend” applied to the bounding box of the collection of objects). The ModContext stores the local OS TM, bounding box of the application of the modifier instance, and a LocalModData ptr, which points to a cache of modifier info that needs to be kept separate for each node.

Normally, to retrieve the ModContexts for nodes, you have to start with a given instance of the actual modifier (or “modapp”) from the derived object, and use it to iterate over the various node-associated ModContexts that it “owns”. Alternatively, you can use Interface::GetModContexts to get a list of ModContexts and associated nodes. In general, it’s often easier for the developer if the original developer of the modifier provides APIs that essentially wrap this functionality, rather than having a developer manually iterate over a modifiers’ ModContexts.

For this sample, we just want the basic class definition, to access the given paramblock at the right object offset. We do this and extract the bend angle out of the BendMod pblock. The bend angle will not be node specific (a single bend applied to multiple nodes has a single bend angle)

We then iterate over the remaining modifiers (since it’s legal to have multiple Bend modifiers associated with one derived object) and any other derived objects in the pipeline.

Try it

For this part first look at the added BendMod declaration in exporter.h in Phase 3. Again, this isn’t necessarily the preferred way of doing things, as noted above.
Look then at the code added to the end of ExportGeomObject. Look specifically at the portion that gets the ObjectRef, and looks for IDerivedObjects and gets the modifiers, if any. Skip the rest (related to the key animations) for the next section.

Animated Parameters

3ds max makes heavy use of animated parameters in parameter blocks to make things easier for animators. Game engines typically don’t need this information, but it’s possible that they might.

For this tutorial, we’ll get the keyframe values of the just-recently-added bend angle, if any exist. We assume that the pblock bend angle value is controlled by a controller that supports keyframes, and we also assume that only the three basic float keyframe controllers (linear, bezier, and TCB) are supported. Given this, we get the keycontroller interface, get the number of keys, loop over the keys and output the angle value and frame for the given key.

Note that for animated TM information, the best bet is to either get TMController information, if the controller is keyframed and you can imitate the interpolation in your engine, or iterate over the TM in each frame and output the TM. The ASCIIEXP exporter demonstrates an example of this.

Try it

Now examine the part of the updated ExportGeomObject that gets the keyframes out of the bend modifier angle value. Notice that the code assumes a controller is available for the angle param that is keyframeable. If this were not the case, we’d have to sample.
If you have the phase3 project set, you can try building it, and creating a scene in 3ds max with a cylinder or other primitive that has an animated bend applied, then exporting the object to look at the results.

Bones and IK

Often useful for game engines is exporting bone and IK information. Unfortunately, 3ds max default Bones and IK system is mostly closed and we can only export minimal information from it. In general, 3ds max bones are best used via additional means, such as the Skin modifier. See COMSkin for a partial example of exporting skin information.

Since it’s non trivial, and we’re trying to keep this tutorial simple, we’ll just discuss some possible ways for exporting bones and IK information.

Bones are linked via node hierarchy. There is always a single base node, that is controlled by a IKMasterController. All other bones in the hierarchy are controlled by IKSlaveControllers. During IK solving, the system calls various Control level methods to determine the results on the IK end effector. 3ds max IK controllers computer the results, but use core code to do this, so the solution process is somewhat hidden.

PHASE 4: CUSTOM DATA

Source code for Phase 4: phase4.zip

With most game engine situations, you’ll want to export additional non-3ds max custom node data to be interpreted only by your engine. This can include anything from “power-up” object properties, to special global illumination data, to anything in-between.

As it turns, there are several ways to apply custom data in 3ds max . These can be broken up as follows:

Per-node custom data
Per-mesh-vertex custom data
Texture-channel custom data

Per-node custom data -- AppData

One of the most basic ways to associate any extra custom data with a given 3ds max node is via something called “AppData”. AppData is basically a chunk of data associated with any animatable (note that this can include things like controllers, modifiers and materials, along with typical scene nodes) that can be attached and retrieved from an animatable, and will automatically get saved and loaded from the MAX scene file.

AppData is always specified and designed in advance by the 3ds max plug-in developer for a specific purpose – AppData associated with animatables have ClassIDs identifying the plugin/object that originally created and attached the appdata.

For this tutorial, we add a simple ExportAppData method, and only call it when processing geomobjects (again, for simplicity). We use the appdata classID defined in the SDK “AppData” utility sample SDK\SAMPLES\UTILITY\APPDATA.CPP, and cast the resulting appdatachunk (if found) to a TCHAR and output it.

One notable caveat: AppData does not get copied if a scene node is copied by the user (via shift-drag or the like).

Per-node custom data – UserProps

Another way to associate custom data with a 3ds max node is using “UserProps”. There are APIs off Inode that support associating string, integer, float, or boolean data with a scene node.

The properties are “named”, and for this tutorial, we’ll use names “UserBool”, “UserFloat”, “UserInt”, “UserString”. Create another utility method (ExportUserProps) and call it after calling ExportAppData in GeomObject processing.

Caveat 2: UserProp data does copy when nodes are copied.

Per-Vertex custom data

3ds max provides a way to embed basic numeric (float) information with each vertex in a polygonal mesh. This results in a single value per mesh vertex, so a simple box would usually have 8 possible custom values.

In 3ds max, there are up to 99 vertex-data channels. Don’t confuse these with the 99 texture channels (admittedly, this is pretty easy to confuse), accessed via APIs off the Mesh class (vDataSupport and vertexFloat). For 3ds max, channel 0 is normally the soft-selection data channel, and channel 1 is normally the vertex weight channel.

Per-Face custom data

Beginning in 3ds max R4.0 a new capability to host user-defined data on a per-face basis was introduced.

This feature allows a Mesh object to support up to 99 custom data channels for Faces. Each channel provides an array to store data as defined by the developer. The types of data will often be standard items such as floats and ints, however, pointers to more sophisticated objects may be stored as well.

There are already existing samples in the MaxSDK that cover this great detail. Two of these samples are the PerFaceData modifier (maxsdk\samples\howto\perfacedata) and its exporter FaceDataExport ( maxsdk\samples\howto\perfacedata\facedataexport ).

For purposes of this tutorial, the MyExporter code implements the same functionality that is found in FaceDataExport. So, if you apply the PerFaceData modifier to a test object in your scene, MyExporter will find that applied per-face data and export it.

Much more detailed information can be found in the MaxSDK help documentation under the topics "What's New in the Max 4.0 SDK : Custom Face Data Storage", "Class IFaceDataMgr", and "Class IFaceDataChannel".

Texture-channel custom data

The texture channels we talked about when exporting node texture information can, in fact, be used for any floating-point data, not necessarily just UVW data.

The important different herein between texture channel data and per-vertex data is that each mesh (and patch) face has its own “set” of texture “vertices’. So using the simple box example given previously, a single custom texture channel can contain 24 separate custom values.

We’ve already exported the texture channel data, so we won’t code this again. An ADN white paper details various strategies and ways to use the extra texture channels for custom data.

Try it

Examine the exporter.cpp in Phase 4. The AppData example in the added ExportAppData method makes the assumption that the appdata was added from a separate utility plugin, and uses the ClassID from this plugin to both find and determine the type of appdata present.
ExportUserProps looks for userprop data named UserBool, UserInt, UserFloat, UserString. As noted in the code, you can actually experiment with this by building the exporter, and in 3ds max , on a given scene object, right-clicking on it, going to the user-defined properties tab, and in the large editbox, typing in something like “UserInt=45”. Doing an export of this should result in the proper userprops data exported.
ExportPerVertData exports the various per-vertex data in a manner similar to the way we exported the texture channel data.

OTHER STRATEGIES, FUTURE DIRECTIONS

The exporter plug-in we’ve created is a somewhat simple example, but provides a pretty broad spectrum of the various parts of the 3ds max architecture.

However, in some circumstances, an exporter may not be enough. The general problem behind the typical use of an exporter with any 3D application is that there is information loss between the application and the eventual game or game engine that uses the exported data. Since information is effectively getting translated between formats, there is bound to be some information that either won’t be possible to replicate in one of the formats.

Additionally, the process is somewhat manual, and prone to errors. A level designer would prefer to use 3ds max as the level engine, but will have to periodically export the data, check it in the game, and tweak. This is the usual process, but in many ways, things are changing to make this more of a way of the past.

The future of 3ds max is one of separation of graphics algorithms from 3D “Design” UI and application “wrappings”. In other words, the basic graphics algorithms will become “portable”. 3ds max itself will become mainly an application wrapper around portable graphics “modules” that can be used in other applications, including games.

Many aspects of 3ds max are already like this. Remember that 3ds max uses the plug-in SDK for a large percentage of the application. SDK and ADN sample code exposes the graphics algorithms used for certain modifiers, etc. that can be ported to a game engine or the like. These sort of things will continue in the future releases of 3ds max .

Already, additional samples emphasize this “separation” concept. The “COMSkin” example demonstrates a way to provide an “external” COM DLL that provides the graphics algorithms (in this case tessellation algorithms), and both 3ds max and Game engine “wrappers” around the external module. In this way, the exact same algorithms can be used by designers in 3ds max and players in the game, and the actual visible output is the same.

As game developers, bear in mind that it can work both ways. If you have a finally tuned piece of code in your current game engine that does a great job with real-time subdivision surfaces, and you want game level designers to be able to see and use the same process in 3ds max , consider exporting the code into a separate module, and writing a 3ds max modifier that wraps around this.

The idea of separating base-level implementation from application-level wrappers is nothing new. However, it’s a very useful idea that can save significant time in the long run.

@王一伟 2007-08-14 16:35 发表评论

函数用const修饰算不算重载

@王一伟 — Sun, 12 Aug 2007 13:14:00 GMT

#include "stdafx.h"

class cls
{
public:
int front( int a) const
  {
   return 20;
  }
int front(int a)
{
  return 10;
}

protected:
private:
};

int _tmain(int argc, _TCHAR* argv[])
{
/*const */cls b;
b.front(1);

return 0;
}

实例b没有const修饰时:
如果有front() const和front()函数运行时进入front()
如果只有front() 运行时进入front()
如果只有front() const 运行时进入front() const

实例b有const修饰时:
如果有front() const和front()函数运行时进入front() const

小弟C++语法不熟悉谁能解释下

@王一伟 2007-08-12 21:14 发表评论

MFC类中获得其它类指针

@王一伟 — Sat, 11 Aug 2007 14:26:00 GMT

MFC类中获得其它类指针
成都：苏颖锋
(vcmfc输入并转贴)

当用VC++的Application Wizard生成除了CDialog Basiced以外的应用程序时，将自动产生视图类、文档类、主帧窗口类、应用程序类等等。一般来说，程序的核心数据及操作在文档类中实现。跟界面有关的数据及操作在视图类中实现。当需要在某个类中使用不属于该类的数据时，必须要取得该数据所属类的指针。从视图类获得文档类的指针是很容易的，用GetDocument即可，这在一般的MFC文档中有介绍，也是编程中极为常用的的操作，比如视图类在进行重画等操作时，往往要用到文档类中的数据。然而只能从视图类获得文档类的指针是远远不够的，每个类都有获得其它各个类指针的一套方法，现归纳如下：

为方便说明，现假设已用Application Wizard生成一个SDI应用程序Test，包含如一几个类：CTestApp,CTestDoc,CTestView,CMainFrm.

1.从视图类获得文档类的指针

如前所述，在视图类中需要引用文档类的地方之前，使用以下语句：
CTextDoc *pDoc=(CTestDoc*)GetDocument();
以后便可使用pDoc指针访问文档类。
此处的强制类型转换在Test应用程序中并不必需，因为该程序中只有一个视图类，并且在Initstance()中用SDI文档模板进行了装配，你可以在Test.cpp中的Initstance()方法中看到以下语句：
CSingleDocTemplate *pDocTemplate;
pDocTemplate=new CSingleDocTemplate(IDR_MAINFRAME,RUNTIME_CLASS(CTestDoc),RUNTIME_CLASS(CMainFrame),
RUNTIME_CLASS(CTestView));
AddDocTemplate(pDocTemplate);
以及TestView.h中的线上定义：
inline CTestDoc* CTestView::GetDocument()
{ return (CTestDoc*)m_pDocument;}
简而言之，就是说CTestView的GetDocument()函数自然而然地认为CTestDoc是与它“相配”的，当生成了一个具有多个视图类的应用程序时（如用CSplitterWnd)将窗口分为两栏，但这两栏并非从同一种视图类派生就属于这种情况。具体实现在本文讨论范围之外），只有一个视图类能与唯一的文档类用文档模板进行装配，那么在另外一个未经装配的类中要取得文档类的指针，则需时行强制类型转换。

2.从文档类取得视图类的指针

CDocument类提供了两个函数用于视图类的定位：GetFirstViewPosition()和GetNextView(),具体语法如下：
virtual POSITION GetFirstViewPosition() const;
virtual CView* GetNextView(POSITION& rPosition) const;
注意：GetNextView()括号中的参数用的是引用方式，因此执行后值可能改变。
GetFirstViewPosition()用于返回第一个视图位置（返回的并非视图类指针，而是一个POSITION类型值），GetNextView()有两个功能：返回下一个视图类的指针以及用引用调动的方式来改变传入的POSITION类型参数的值。很明显，在Test程序中，只有一个视图类，因此只需将这两个函数调用一次即可得到CTestView的指针如下（需定义一个POSITION结构变量来辅助操作）：
CTestView* pTestView;
POSITION pos=GetFirstViewPosition();
pTestView=GetNextView(pos);
这样，便可到了CTestView类的指针pTestView.执行完成几句后，变量pos=NULL,因为没有下一个视图类，自然也没有下一个视图类的POSITION.

但是之几条语句太简单，不具有太强的通用性和安全特征；当象前面说的那样，当要在多个视图为中返回某个指定类的指针时，我们需要遍历所有视图类，直到找到指定类为止。判断一个类指针指向的是否某个类的实例时，可用IsKindOf()成员函数时行检查，如：
pView->IsKindOf(RUNTIME_CLASS(CTestView));
即可检查pView所指是否是CTestView类。
有了以上基础，我们已经可以从文档类取得任何类的指针。为了方便，我们将其作为一个文档类的成员函数，它有一个参数，表示要获得哪个类的指针。实现如下：
CView* CTestDoc::GetVieww(CRuntimeClass* pClass)
{ CView* pView;
POSITION pos=GetFirstViewPosition();
while(pos!=NULL)
{
pView=GetNextView(pos);
if(pView->IsKindOf(pClass))
break;
}
if(!pView->IsKindOf(pClass))
return NULL;
return pView;}
其中用了两次视图类的成员函数IsKindOf()来判断，是因为退出while循环有三种可能：
1.pos为NULL，即已经不存在下一个视图类供操作；
2.pView已符合要求。
3.1和2同是满足。这是因为GetNextView()的功能是将当前视图指针改变成一个视图的位置同时返回当前视图指针，因此pos是pView的下一个视图类的POSITION,完全有可能既是pos==NULL又是pView符合需要。当所需的视图是最后一个视图是最后一个视图类时就如引。因此需采用两次判断。
使用该函数应遵循如下格式（以取得CTestView指针为例）：
CTestView* pTestView=(CTestView*)GetView(RUNTIME_CLASS(CTestView));
RUNTIME_CLASS是一个宏，可以简单地理解它的作用：将类的名字转化为CRuntimeClass为指针。
至于强制类型转换也是为了安全特性考虑的，因为从同一个基类之间的指针类型是互相兼容的。这种强制类型转换也许并不必要，但能避免一些可能出现的麻烦。

3.从一个视图类取得另一视图类的指针

综合1和2，很容易得出视图类之间互相获得指针的方法：就是用文档类作中转，先用1的方法得到文档类的指针，再用2的方法，以文档类的视图定位函数取得另一个视图类。同样，可以实现成一个函数：
（假设要从CTestAView中取得指向其它视图类的指针）
CView* CTestAView::GetView(CRuntimeClass* pClass)
{ CTestDoc* pDoc=(CTestDoc*)GetDocument();
CView* pView;
POSITION pos=pDoc->GetFirstViewPosition();
while(pos!=NULL)
{
pView=pDoc->GetNextView(pos);
if(pView->IsKindOf(pClass))
break;
}
if(!pView->IsKindOf(pClass))
return NULL;
return pView;}
这个函数和2中的GetView()相比，一是多了第一句以取得文档类指针，二是在GetFirstViewPosition()和GetNextView()前加上了文档类指针，以表示它们是文档类成员函数。
有了此函数；当要从CTestAView中取得CTestBView的指针时，只需如下：
CTestBView* pTestbView=(CTestView*)GetView(RUNTIME_CLASS(CTestBView));

4. 从主帧窗口类获得视图类指针

对本文所举的Test这各SDI程序来说，这是简单的，只需用CFrameWnd类的GetActiveView()成员函数即可。格式如下：
CFrameWnd::GetActiveView()
但将此函数应用在MDI应用的CMDIFrameWnd为中时，并不象所想的那样获得当前活动子窗口的视图类，而是返回NULL，这是一个要领性问题。在MDI程序中，CMDIFrameWnd没有和任何视图类发生关系，也就是说没有视图类直接属于它，只有子帧窗口类CMDIChildWnd才是所有子窗口视图类的父窗口。而子帧窗口的父窗口才是CFrameWnd。因此，在MDI程序中获得活动视图类的正确方法应为：先获得活动子帧窗口，再从活动子帧窗口中获得活动视图类：
//获得活动子帧窗口
CMDIChildWnd* pChild=(CMDIChildWnd*)GetActiveFrame();
//或：CMDIChildWnd* pChild=MDIGetActive();
//获得活动子帧窗口的活动视图
CMyView* pView=(CMyView*)pChild->GetActiveView();

5.从视图类中获得主帧窗口类指针：

用函数：CWnd::GetParentFrame()或AfxGetMainWnd();
可达到目的。GetParentFrame()的工作原理是在父窗口链中搜索，直到找到CFrameWnd或其派生类为止，并返回其指针。用法在InfoViewer中有详细介绍。

6.在任何类中获得应用程序类
用MFC全局函数AfxGetApp()可做到。

7.从应用程序类中获得主帧窗口类
CWinThread类有一个数据成员叫m_pMainWnd，由于CWinApp类由CWinThread派生而来，我们的应用程序为又由CWinApp派生而来，所以我们的CTestApp类也有一个m_pMainWnd成员，它所指南的即是CMainFrame类。（需进行合适的强制类型转换）。

总结起来有几点注意：
A.在类A中获得类B的指针时，类A应包含类B的头文件。
B.在很多时候要进行强制类型转换，并要注意括号的括法。
由于派生类和父类指针类型的兼容，使明确区分各个类变得十分重要。在拿不准的时候，最好加上强制类型转换。

@王一伟 2007-08-11 22:26 发表评论

GetProcAddress

@王一伟 — Wed, 08 Aug 2007 15:00:00 GMT

Visual C++
GetProcAddress
显式链接到 DLL 的进程调用 GetProcAddress 来获取 DLL 导出函数的地址。使用返回的函数指针调用 DLL 函数。GetProcAddress 将（由 LoadLibrary、AfxLoadLibrary 或 GetModuleHandle 返回的）DLL 模块句柄和要调用的函数名或函数的导出序号用作参数。

由于是通过指针调用 DLL 函数并且没有编译时类型检查，需确保函数的参数是正确的，以便不会超出在堆栈上分配的内存和不会导致访问冲突。帮助提供类型安全的一种方法是查看导出函数的函数原型，并创建函数指针的匹配 typedef。例如：

typedef UINT (CALLBACK* LPFNDLLFUNC1)(DWORD,UINT);

HINSTANCE hDLL;               // Handle to DLL
LPFNDLLFUNC1 lpfnDllFunc1;    // Function pointer
DWORD dwParam1;
UINT  uParam2, uReturnVal;

hDLL = LoadLibrary("MyDLL");
if (hDLL != NULL)
{
   lpfnDllFunc1 = (LPFNDLLFUNC1)GetProcAddress(hDLL,
                                           "DLLFunc1");
   if (!lpfnDllFunc1)
   {
      // handle the error
      FreeLibrary(hDLL);
      return SOME_ERROR_CODE;
   }
   else
   {
      // call the function
      uReturnVal = lpfnDllFunc1(dwParam1, uParam2);
   }
}

调用 GetProcAddress 时指定所需函数的方式取决于 DLL 的生成方式。

仅当要链接到的 DLL 是用模块定义 (.def) 文件生成的，并且序号在 DLL 的 .def 文件的 EXPORTS 部分中与函数一起列出时，才能获取导出序号。如果 DLL 具有许多导出函数，则相对于使用函数名，使用导出序号调用 GetProcAddress 的速度稍快一些，因为导出序号是 DLL 导出表的索引。使用导出序号，GetProcAddress 可直接定位函数，而不是将指定名称与 DLL 导出表中的函数名进行比较。但是，仅当有权控制 .def 文件中导出函数的序号分配时，才应使用导出序号调用 GetProcAddress。

@王一伟 2007-08-08 23:00 发表评论

常用字符串件的类型转换

@王一伟 — Tue, 17 Jul 2007 03:55:00 GMT

常用字符串件的类型转换。

From	To	Sample
字符串常量	BSTR	Right: BSTR bs = ::SysAllocString(_T("Test string")); … ::SysFreeString(); Wrong: BSTR bs = _T("Test string"); //ERROR
LPWSTR / LPCWSTR / WCHAR* / wchar_t	BSTR	Right: LPCTSTR sz1 = _T("Test String"); BSTR bs = ::SysAllocString(sz1); … ::SysFreeString(); Wrong: LPTSTR sz1 = _T("Test String"); BSTR bs = sz1; //ERROR
BSTR	LPCWSTR / const WCHAR * / const wchar_t *	Right: BSTR bs = ...; // ... LPCTSTR sz = static_castbs; ... ::SysFreeString(bs); //Never use sz after this line Wrong: BSTR bs = ...; // ... LPCTSTR sz = bs; ... ::SysFreeString(bs); //Never use sz after this line _tcslen(sz); //ERROR
BSTR	LPWSTR / WCHAR* / wchar_t*	Right: BSTR bs = ...; // //... UINT len = ::SysStringLen(bs); // Do not modify the BSTR content by // C/C++ string functions LPTSTR sz = new TCHAR[len+1]; _tcsncpy(sz, bs, len); ::SysFreeString(bs); delete []sz; Wrong: BSTR bs = ...; // //... // Do not modify the BSTR content by // C/C++ string functions LPTSTR sz = bs; //Error
CString	BSTR	Right: CString str1 = ...; BSTR bs = str1.AllocSysString(); SomeMethod(bs); // void SomeMethod([in]BSTR) ::SysFreeString(bs); CComBSTR bs1(static_cast(str1)); SomeMethod(static_cast (bs1) ); // void SomeMethod([in] BSTR ) _bstr_t bs2( static_cast(str1)); SomeMethod(static_cast (bs2) ); Wrong: CString str1 = ...; SomeMethod(str1.AllocSysString()); // No one will releasee the return BSTR of // str1.AllocSysString()
BSTR	CString	Right: BSTR bs = SysAllocString(_T(“Test”)); CString str1(bs); CString str2; Str2 = bs; SysFreeString(bs); // Never forget this line
char* / LPSTR / LPCSTR	BSTR	Right: Solution 1： char str[MAX_STR_LEN] = "ANSI string"; WCHAR wstr[MAX_WSTR_LEN]; // Convert ANSI to Unicode MultiByteToWideChar( CP_ACP, 0, str, strlen(str)+1, wstr, sizeof(wstr)/sizeof(wstr[0]) ); BSTR bs1 = ::SysAllocString(wstr); CString cs = str; BSTR bs2 = cs.AllocSysString() Solution 2： char str[MAX_STR_LEN] = "ANSI string"; _bstr_t bs1(str); CComBSTR bs2(str); Wrong: char str = "ANSI string"; BSTR bstr1 = SysAllocString( (const OLECHAR) str);
BSTR	char* / LPSTR / LPCSTR	Right: Solution 1： char str[MAX_STR_LEN]; BSTR bs = ::SysAllocString(L"Test"); // Convert ANSI to Unicode WideCharToMultiByte( CP_ACP, 0, (LPCWSTR)bs, -1, str, MAX_STR_LEN, NULL, NULL ); ::SysFreeString(bs); Solution 2： BSTR bs = ::SysAllocString(L"Test"); _bstr_t bs1(bs, false); const char* str = static_cast bs1; Wrong: BSTR bstr1 = SysAllocString(L”ANSI string"); char str = (char) bstr1;

IMPORTANT: 上面所有的例子都是按照UNICODE应用程序设计的。并且不考虑BSTR中包含多个字串的情况，也就是BSTR只在结束的位置有一个0结束符。对于MBCS/ANSI程序，可以参考上面的例子。主要区别是对于现在的COM版本OLECHAR是wchar_t，但是TCHAR 对于UNICODE程序才是wchar_t。

@王一伟 2007-07-17 11:55 发表评论

The PIMPL idiom

@王一伟 — Mon, 16 Jul 2007 06:51:00 GMT

The PIMPL idiom

In C++ when anything in a header file changes, all code that includes the header (either directly or indirectly) must be recompiled. To minimalize this we use PIMPL idiom:

// file x.h
class X
{
public:
// public members
protected:
// protected members
private:
// pointer to forward declared class
class XImpl *pimpl_;  // opaque pointer
};

Questions: -- What should go into XImpl? Options are:

Put all private data but not functions into XImpl.: Not too bad, but there is better
Put all private members into XImpl.
Put all private and protected members into XImpl. Bad, protected members must be in X
Make XImpl entirely the class that X would have been, and write X as only the public interface made up entirely of simple forwarding functions (handle/body variant).

-- Does XImpl require a pointer back to the X object?

Caveats:

You can't hide virtual member functions in the Pimpl (here private inheritance differs from membership)
Functions in Pimpl may require a "back pointer" to the visible object (by convention that is called: self_.
Often the best compromise is to use Option 2, and in addition to put into XImpl only rhose non-private functions that need to be called by private ones.
4th is better over 2nd not needed "back pointer", but X is useless for inheritance.

PIPML has some drawbacks, like allocating/deallocating objects in the heap, which could be slow.

What about this "optimalization"?

// file: y.h
class Y
{
//...
static const size_t sizeofx = /* ... */;
char x_[sizeofx];
};
// file: y.cpp
#include "x.h"
Y::Y()
{
assert( sizeofx >= sizeof(X) );
new(&x_[0]) X;
}
Y::~Y()
{
(reinterpret_cast(&x_[0]))->~X();
}

Questions:

What is the Pimpl space overhead?
What is the performance overhead?

Space overhead:

#include 
using namespace std;
struct X {
char c;
struct XImpl *pimpl_;
};
struct XImpl { char c; };
int main()
{
cout << sizeof(XImpl) << '\t' << sizeof(X) << endl;
return 0;
}
// result: 1    8

Runtime overhead:

allocation/deallocation cost: relativelly expensive
indirect access of private members (+ back pointer)
alignment problems: new guaranties, that object will align properly, char[] buffers doesn't!
X must not use the default assignmentoperator=()
If sizeof(XImpl) grows greater then sizeofx, we need to update the source.

// file x.h
class X
{
//...
struct XImpl *pimpl_;
};
// file x.cpp
#include "x.h"
struct XImpl
{
// private stuff here ...
static void *operator new(size_t)   { /*...*/ }
static void *operator delete(void*) { /*...*/ }
};
X::X() : pimpl_( new XImpl ) { }
X::~X() { delete pimpl_; pimpl_ = 0; }

@王一伟 2007-07-16 14:51 发表评论

SQL参考

@王一伟 — Sat, 26 May 2007 16:23:00 GMT

SQL参考

一、资料定义ｄｄｌ（data definition language)
资料定语言是指对资料的格式和形态下定义的语言，他是每个资料库要建立时候时首先
要面对的，举凡资料分哪些表格关系、表格内的有什麽栏位主键、表格和表格之间互相
参考的关系等等，都是在开始的时候所必须规划好的。

１、建表格：
create table table_name(
column1 datatype [not null] [not null primary key],
column2 datatype [not null],
...）
说明：　
datatype --是资料的格式，详见表。
nut null --可不可以允许资料有空的（尚未有资料填入）。
primary key --是本表的主键。

２、更改表格　
alter table table_name
add column column_name datatype
说明：增加一个栏位（没有删除某个栏位的语法。
alter table table_name
add primary key (column_name)
说明：更改表得的定义把某个栏位设为主键。
alter table table_name
drop primary key (column_name)
说明：把主键的定义删除。

３、建立索引　
create index index_name on table_name (column_name)
说明：对某个表格的栏位建立索引以增加查询时的速度。

４、删除　
drop table_name
drop index_name

二、的资料形态 datatypes
smallint
16 位元的整数。
interger
32 位元的整数。
decimal(p,s)
p 精确值和 s 大小的十进位整数，精确值p是指全部有几个数(digits)大小值，s是指小
数
点後有几位数。如果没有特别指定，则系统会设为 p=5; s=0 。
float
32位元的实数。
double
64位元的实数。
char(n)
n 长度的字串，n不能超过 254。
varchar(n)
长度不固定且其最大长度为 n 的字串，n不能超过 4000。
graphic(n)
和 char(n) 一样，不过其单位是两个字元 double-bytes， n不能超过127。这个形态是
为
了支援两个字元长度的字体，例如中文字。
vargraphic(n)
可变长度且其最大长度为 n 的双字元字串，n不能超过 2000。
date
包含了年份、月份、日期。
time
包含了小时、分钟、秒。
timestamp
包含了年、月、日、时、分、秒、千分之一秒。

三、资料操作ｄｍｌ（data manipulation language)
资料定义好之後接下来的就是资料的操作。资料的操作不外乎增加资料（insert)、查询
资料（query）、更改资料（update) 、删除资料（delete）四种模式，以下分别介绍
他们的语法：

１、增加资料：
insert into table_name (column1,column2,...)
values ( value1,value2, ...)
说明：
1.若没有指定column 系统则会按表格内的栏位顺序填入资料。
2.栏位的资料形态和所填入的资料必须吻合。
3.table_name 也可以是景观 view_name。

insert into table_name (column1,column2,...)
select columnx,columny,... from another_table
说明：也可以经过一个子查询（subquery）把别的表格的资料填入。

２、查询资料：
基本查询
select column1,columns2,...
from table_name
说明：把table_name 的特定栏位资料全部列出来
select *
from table_name
where column1 = xxx
[and column2 > yyy] [or column3 <> zzz]
说明：
1.'*'表示全部的栏位都列出来。
2.where 之後是接条件式，把符合条件的资料列出来。

select column1,column2
from table_name
order by column2 [desc]
说明：order by 是指定以某个栏位做排序，[desc]是指从大到小排列，若没有指明，则
是从小到大
排列

组合查询
组合查询是指所查询得资料来源并不只有单一的表格，而是联合一个以上的
表格才能够得到结果的。
select *
from table1,table2
where table1.colum1=table2.column1
说明：
1.查询两个表格中其中 column1 值相同的资料。
2.当然两个表格相互比较的栏位，其资料形态必须相同。
3.一个复杂的查询其动用到的表格可能会很多个。

整合性的查询：
select count (*)
from table_name
where column_name = xxx
说明：
查询符合条件的资料共有几笔。
select sum(column1)
from table_name
说明：
1.计算出总和，所选的栏位必须是可数的数字形态。
2.除此以外还有 avg() 是计算平均、max()、min()计算最大最小值的整合性查询。
select column1,avg(column2)
from table_name
group by column1
having avg(column2) > xxx
说明：
1.group by: 以column1 为一组计算 column2 的平均值必须和 avg、sum等整合性查询
的关键字
一起使用。
2.having : 必须和 group by 一起使用作为整合性的限制。

复合性的查询
select *
from table_name1
where exists (
select *
from table_name2
where conditions )
说明：
1.where 的 conditions 可以是另外一个的 query。
2.exists 在此是指存在与否。
select *
from table_name1
where column1 in (
select column1
from table_name2
where conditions )
说明：　
1. in 後面接的是一个集合，表示column1 存在集合里面。
2. select 出来的资料形态必须符合 column1。

其他查询
select *
from table_name1
where column1 like 'x%'
说明：like 必须和後面的'x%' 相呼应表示以 x为开头的字串。
select *
from table_name1
where column1 in ('xxx','yyy',..)
说明：in 後面接的是一个集合，表示column1 存在集合里面。
select *
from table_name1
where column1 between xx and yy
说明：between 表示 column1 的值介於 xx 和 yy 之间。

３、更改资料：
update table_name
set column1='xxx'
where conditoins
说明：
1.更改某个栏位设定其值为'xxx'。
2.conditions 是所要符合的条件、若没有 where 则整个 table 的那个栏位都会全部被
更改。

４、删除资料：
delete from table_name
where conditions
说明：删除符合条件的资料。

说明：关于where条件后面如果包含有日期的比较，不同数据库有不同的表达式。具体如
下：
(1)如果是access数据库，则为：where mydate>#2000-01-01#
(2)如果是oracle数据库，则为：where mydate>cast('2000-01-01' as date)
或：where mydate>to_date('2000-01-01','yyyy-mm-dd')
在delphi中写成：
thedate='2000-01-01';
query1.sql.add('select * from abc where mydate>cast('+''''+thedate+''''+' as
date)');

如果比较日期时间型，则为：
where mydatetime>to_date('2000-01-01 10:00:01','yyyy-mm-dd hh24:mi:ss')

@王一伟 2007-05-27 00:23 发表评论

宽度优先搜索

@王一伟 — Fri, 13 Apr 2007 08:20:00 GMT

宽度优先搜索 BFS

宽度优先搜索算法（又称广度优先搜索）是最简便的图的搜索算法之一，这一算法也是很多重要的图的算法的原型。Dijkstra单源最短路径算法和Prim最小生成树算法都采用了和宽度优先搜索类似的思想。

已知图G=(V,E)和一个源顶点s，宽度优先搜索以一种系统的方式探寻G的边，从而“发现”s所能到达的所有顶点，并计算s到所有这些顶点的距离(最少边数)，该算法同时能生成一棵根为s且包括所有可达顶点的宽度优先树。对从s可达的任意顶点v，宽度优先树中从s到v的路径对应于图G中从s到v的最短路径，即包含最小边数的路径。该算法对有向图和无向图同样适用。

之所以称之为宽度优先算法，是因为算法自始至终一直通过已找到和末找到顶点之间的边界向外扩展，就是说，算法首先搜索和s距离为k的所有顶点，然后再去搜索和S距离为k+l的其他顶点。

为了保持搜索的轨迹，宽度优先搜索为每个顶点着色：白色、灰色或黑色。算法开始前所有顶点都是白色，随着搜索的进行，各顶点会逐渐变成灰色，然后成为黑色。在搜索中第一次碰到一顶点时，我们说该顶点被发现，此时该顶点变为非白色顶点。因此，灰色和黑色顶点都已被发现，但是，宽度优先搜索算法对它们加以区分以保证搜索以宽度优先的方式执行。若(u,v)∈E且顶点u为黑色，那么顶点v要么是灰色，要么是黑色，就是说，所有和黑色顶点邻接的顶点都已被发现。灰色顶点可以与一些白色顶点相邻接，它们代表着已找到和未找到顶点之间的边界。

在宽度优先搜索过程中建立了一棵宽度优先树，起始时只包含根节点，即源顶点s.在扫描已发现顶点u的邻接表的过程中每发现一个白色顶点v，该顶点v及边(u,v)就被添加到树中。在宽度优先树中，我们称结点u 是结点v的先辈或父母结点。因为一个结点至多只能被发现一次，因此它最多只能有--个父母结点。相对根结点来说祖先和后裔关系的定义和通常一样：如果u处于树中从根s到结点v的路径中，那么u称为v的祖先，v是u的后裔。

下面的宽度优先搜索过程BFS假定输入图G=(V,E)采用邻接表表示，对于图中的每个顶点还采用了几种附加的数据结构，对每个顶点u∈V，其色彩存储于变量color[u]中，结点u的父母存于变量π[u]中。如果u没有父母(例如u=s或u还没有被检索到)，则 π[u]=NIL，由算法算出的源点s和顶点u之间的距离存于变量d[u]中，算法中使用了一个先进先出队列Q来存放灰色节点集合。其中head[Q]表示队列Q的队头元素，Enqueue(Q,v)表示将元素v入队， Dequeue(Q)表示对头元素出队；Adj[u]表示图中和u相邻的节点集合。

procedure BFS(G,S);

begin

1. for 每个节点u∈V[G]- do

begin

2.       color[u]←White;

3.       d[u]←∞;

4.       π[u]←NIL;

end;

5. color[s]←Gray;

6. d[s]←0;

7. π[s]←NIL;

8. Q←

9. while Q≠φ do

begin

10.    u←head[Q];

11.    for 每个节点v∈Adj[u] do

12.       if color[v]=White then

begin

13.          color[v]←Gray;

14.          d[v]←d[v]+1;

15.          π[v]←u;

16.          Enqueue(Q,v);

end;

17.    Dequeue(Q);

18.    color[u]←Black;

end;

end;

图1展示了用BFS在例图上的搜索过程。黑色边是由BFS产生的树枝。每个节点u内的值为d[u]，图中所示的队列Q是第9-18行while循环中每次迭代起始时的队列。队列中每个结点下面是该结点与源结点的距离。

图1 BFS在一个无向图上的执行过程

过程BFS按如下方式执行，第1-4行置每个结点为白色，置d[u]为无穷大，每个结点的父母置为NIL，第5行置源结点S为灰色，即意味着过程开始时源结点已被发现。第6行初始化d[s]为0，第7行置源结点的父母结点为NIL，第8行初始化队列0，使其仅含源结点s，以后Q队列中仅包含灰色结点的集合。

程序的主循环在9-18行中，只要队列Q中还有灰色结点，即那些已被发现但还没有完全搜索其邻接表的结点，循环将一直进行下去。第10行确定队列头的灰色结点为u。第11-16行的循环考察u的邻接表中的每一个顶点v。如果v是白色结点，那么该结点还没有被发现过，算法通过执行第13-16行发现该结点。首先它被置为灰色，距离d[v]置为d[u]+1，而后u被记为该节点的父母，最后它被放在队列Q的队尾。当结点u的邻接表中的所有结点都被检索后，第17 -18行使u弹出队列并置成黑色。

分析

在证明宽度优先搜索的各种性质之前，我们先做一些相对简单的工作 ——分析算法在图G=(V,E)之上的运行时间。在初始化后，再没有任何结点又被置为白色。因此第12行的测试保证每个结点至多只能迸人队列一次，因而至多只能弹出队列一次。入队和出队操作需要O(1)的时间，因此队列操作所占用的全部时间为O(V)，因为只有当每个顶点将被弹出队列时才会查找其邻接表，因此每个顶点的邻接表至多被扫描一次。因为所有邻接表的长度和为Q(E)，所以扫描所有邻接表所花费时间至多为O(E)。初始化操作的开销为O(V)，因此过程BFS的全部运行时间为O(V+E)，由此可见，宽度优先搜索的运行时间是图的邻接表大小的一个线性函数。

@王一伟 2007-04-13 16:20 发表评论

正则表达式

@王一伟 — Tue, 10 Apr 2007 01:59:00 GMT

最近看编译原理，找了些正则表达式的资料,先贴上来，晚上看过了做个总结

正则表达式入门.rar（.swf）
ExpressoBetaSetup.msi

正则表达式之道

原著：Steve Mansour
sman@scruznet.com
Revised: June 5, 1999
(copied by jm /at/ jmason.org from http://www.scruz.net/%7esman/regexp.htm, after the original disappeared! )

翻译：Neo Lee
neo.lee@gmail.com
2004年10月16日

英文版原文

译者按：原文因为年代久远，文中很多链接早已过期（主要是关于vi、sed等工具的介绍和手册），本译文中已将此类链接删除，如需检查这些链接可以查看上面链接的原文。除此之外基本照原文直译，括号中有“译者按”的部分是译者补充的说明。

什么是正则表达式

一个正则表达式，就是用某种模式去匹配一类字符串的一个公式。很多人因为它们看上去比较古怪而且复杂所以不敢去使用——很不幸，这篇文章也不能够改变这一点，不过，经过一点点练习之后我就开始觉得这些复杂的表达式其实写起来还是相当简单的，而且，一旦你弄懂它们，你就能把数小时辛苦而且易错的文本处理工作压缩在几分钟（甚至几秒钟）内完成。正则表达式被各种文本编辑软件、类库（例如Rogue Wave的tools.h++）、脚本工具（像awk/grep/sed）广泛的支持，而且像Microsoft的Visual C++这种交互式IDE也开始支持它了。

我们将在如下的章节中利用一些例子来解释正则表达式的用法，绝大部分的例子是基于vi中的文本替换命令和grep文件搜索命令来书写的，不过它们都是比较典型的例子，其中的概念可以在sed、awk、perl和其他支持正则表达式的编程语言中使用。你可以看看不同工具中的正则表达式这一节，其中有一些在别的工具中使用正则表达式的例子。还有一个关于vi中文本替换命令（s）的简单说明附在文后供参考。

正则表达式基础

正则表达式由一些普通字符和一些元字符（metacharacters）组成。普通字符包括大小写的字母和数字，而元字符则具有特殊的含义，我们下面会给予解释。

在最简单的情况下，一个正则表达式看上去就是一个普通的查找串。例如，正则表达式"testing"中没有包含任何元字符，，它可以匹配"testing"和"123testing"等字符串，但是不能匹配"Testing"。

要想真正的用好正则表达式，正确的理解元字符是最重要的事情。下表列出了所有的元字符和对它们的一个简短的描述。

*元字符*		描述

`.`		匹配任何单个字符。例如正则表达式`r.t`匹配这些字符串：rat、rut、r t，但是不匹配root。
`$`		匹配行结束符。例如正则表达式`weasel$` 能够匹配字符串"He's a weasel"的末尾，但是不能匹配字符串"They are a bunch of weasels."。
^		匹配一行的开始。例如正则表达式`^When in`能够匹配字符串"When in the course of human events"的开始，但是不能匹配"What and When in the"。
*``**		匹配0或多个正好在它之前的那个字符。例如正则表达式*`.`**意味着能够匹配任意数量的任何字符。
`\`		这是引用府，用来将这里列出的这些元字符当作普通的字符来进行匹配。例如正则表达式`\$`被用来匹配美元符号，而不是行尾，类似的，正则表达式`\.`用来匹配点字符，而不是任何字符的通配符。
`[ ]` `[c1-c2]` `[^c1-c2]`		匹配括号中的任何一个字符。例如正则表达式`r[aou]t`匹配rat、rot和rut，但是不匹配ret。可以在括号中使用连字符-来指定字符的区间，例如正则表达式`[0-9]`可以匹配任何数字字符；还可以制定多个区间，例如正则表达式`[A-Za-z]`可以匹配任何大小写字母。另一个重要的用法是“排除”，要想匹配除了指定区间之外的字符——也就是所谓的补集——在左边的括号和第一个字符之间使用^字符，例如正则表达式`[^269A-Z]` 将匹配除了2、6、9和所有大写字母之外的任何字符。
`\< \>`		匹配词（word）的开始（\<）和结束（\>）。例如正则表达式`\`能够匹配字符串"for the wise"中的"the"，但是不能匹配字符串"otherwise"中的"the"。注意：这个元字符不是所有的软件都支持的。
``		将 $ 和 $ 之间的表达式定义为“组”（group），并且将匹配这个表达式的字符保存到一个临时区域（一个正则表达式中最多可以保存9个），它们可以用 `\1` 到`\9` 的符号来引用。
`\|`		将两个匹配条件进行逻辑“或”（Or）运算。例如正则表达式`(him\|her)` 匹配"it belongs to him"和"it belongs to her"，但是不能匹配"it belongs to them."。注意：这个元字符不是所有的软件都支持的。
`+`		匹配1或多个正好在它之前的那个字符。例如正则表达式`9+`匹配9、99、999等。注意：这个元字符不是所有的软件都支持的。
`?`		匹配0或1个正好在它之前的那个字符。注意：这个元字符不是所有的软件都支持的。
`\{`i`\}` `\{`i`,`j`\}`		匹配指定数目的字符，这些字符是在它之前的表达式定义的。例如正则表达式`A[0-9]\{3\}` 能够匹配字符"A"后面跟着正好3个数字字符的串，例如A123、A348等，但是不匹配A1234。而正则表达式`[0-9]\{4,6\}` 匹配连续的任意4个、5个或者6个数字字符。注意：这个元字符不是所有的软件都支持的。

最简单的元字符是点，它能够匹配任何单个字符（注意不包括新行符）。假定有个文件test.txt包含以下几行内容：

he is a rat

he is in a rut

the food is Rotten

I like root beer

我们可以使用grep命令来测试我们的正则表达式，grep命令使用正则表达式去尝试匹配指定文件的每一行，并将至少有一处匹配表达式的所有行显示出来。命令

grep r.t test.txt

在test.txt文件中的每一行中搜索正则表达式r.t，并打印输出匹配的行。正则表达式r.t匹配一个r接着任何一个字符再接着一个t。所以它将匹配文件中的rat和rut，而不能匹配Rotten中的Rot，因为正则表达式是大小写敏感的。要想同时匹配大写和小写字母，应该使用字符区间元字符（方括号）。正则表达式[Rr]能够同时匹配R和r。所以，要想匹配一个大写或者小写的r接着任何一个字符再接着一个t就要使用这个表达式：[Rr].t。

要想匹配行首的字符要使用抑扬字符（^）——又是也被叫做插入符。例如，想找到text.txt中行首"he"打头的行，你可能会先用简单表达式he，但是这会匹配第三行的the，所以要使用正则表达式^he，它只匹配在行首出现的h。

有时候指定“除了×××都匹配”会比较容易达到目的，当抑扬字符（^）出现在方括号中是，它表示“排除”，例如要匹配he ，但是排除前面是t or s的情性（也就是the和she），可以使用：[^st]he。

可以使用方括号来指定多个字符区间。例如正则表达式[A-Za-z]匹配任何字母，包括大写和小写的；正则表达式[A-Za-z][A-Za-z]* 匹配一个字母后面接着0或者多个字母（大写或者小写）。当然我们也可以用元字符+做到同样的事情，也就是：[A-Za-z]+ ，和[A-Za-z][A-Za-z]*完全等价。但是要注意元字符+ 并不是所有支持正则表达式的程序都支持的。关于这一点可以参考后面的正则表达式语法支持情况。

要指定特定数量的匹配，要使用大括号（注意必须使用反斜杠来转义）。想匹配所有100和1000的实例而排除10和10000，可以使用：10\{2,3\}，这个正则表达式匹配数字1后面跟着2或者3个0的模式。在这个元字符的使用中一个有用的变化是忽略第二个数字，例如正则表达式0\{3,\} 将匹配至少3个连续的0。

简单的例子

这里有一些有代表性的、比较简单的例子。

*vi 命令*	作用

*`:%s/ / /g`**	把一个或者多个空格替换为一个空格。
*`:%s/ $//`**	去掉行尾的所有空格。
`:%s/^/ /`	在每一行头上加入一个空格。
*`:%s/^[0-9][0-9] //`**	去掉行首的所有数字字符。
`:%s/b[aeio]g/bug/g`	将所有的bag、beg、big和bog改为bug。
`:%s/t$[aou]$g/h\1t/g`	将所有tag、tog和tug分别改为hat、hot和hug（注意用group的用法和使用\1引用前面被匹配的字符）。

中级的例子（神奇的咒语）

例1

将所有方法foo(a,b,c)的实例改为foo(b,a,c)。这里a、b和c可以是任何提供给方法foo()的参数。也就是说我们要实现这样的转换：

之前		之后
`foo(10,7,2)`		`foo(7,10,2)`
`foo(x+13,y-2,10)`		`foo(y-2,x+13,10)`
`foo( bar(8), x+y+z, 5)`		`foo( x+y+z, bar(8), 5)`

下面这条替换命令能够实现这一魔法：

:%s/foo($[^,]*$,$[^,]*$,$[^)]*$)/foo(\2,\1,\3)/g

现在让我们把它打散来加以分析。写出这个表达式的基本思路是找出foo()和它的括号中的三个参数的位置。第一个参数是用这个表达式来识别的：：$[^,]*$，我们可以从里向外来分析它：

`[^,]`		除了逗号之外的任何字符
*`[^,]`**		0或者多个非逗号字符
*`$[^,]$`**		将这些非逗号字符标记为`\1`，这样可以在之后的替换模式表达式中引用它
*`$[^,]$,`**		我们必须找到0或者多个非逗号字符后面跟着一个逗号，并且非逗号字符那部分要标记出来以备后用。

现在正是指出一个使用正则表达式常见错误的最佳时机。为什么我们要使用[^,]*这样的一个表达式，而不是更加简单直接的写法，例如：.*，来匹配第一个参数呢？设想我们使用模式.*来匹配字符串"10,7,2"，它应该匹配"10,"还是"10,7,"？为了解决这个两义性（ambiguity），正则表达式规定一律按照最长的串来，在上面的例子中就是"10,7,"，显然这样就找出了两个参数而不是我们期望的一个。所以，我们要使用[^,]*来强制取出第一个逗号之前的部分。

这个表达式我们已经分析到了：foo($[^,]*$，这一段可以简单的翻译为“当你找到foo(就把其后直到第一个逗号之前的部分标记为\1”。然后我们使用同样的办法标记第二个参数为\2。对第三个参数的标记方法也是一样，只是我们要搜索所有的字符直到右括号。我们并没有必要去搜索第三个参数，因为我们不需要调整它的位置，但是这样的模式能够保证我们只去替换那些有三个参数的foo()方法调用，在foo()是一个重载（overoading）方法时这种明确的模式往往是比较保险的。然后，在替换部分，我们找到foo()的对应实例，然后利用标记好的部分进行替换，是的第一和第二个参数交换位置。

例2

假设有一个CSV（comma separated value）文件，里面有一些我们需要的信息，但是格式却有问题，目前数据的列顺序是：姓名，公司名，州名缩写，邮政编码，现在我们希望讲这些数据重新组织，以便在我们的某个软件中使用，需要的格式为：姓名，州名缩写-邮政编码，公司名。也就是说，我们要调整列顺序，还要合并两个列来构成一个新列。另外，我们的软件不能接受逗号前后面有任何空格（包括空格和制表符）所以我们还必须要去掉逗号前后的所有空格。

这里有几行我们现在的数据：

Bill Jones, HI-TEK Corporation , CA, 95011

Sharon Lee Smith, Design Works Incorporated, CA, 95012

B. Amos , Hill Street Cafe, CA, 95013

Alexander Weatherworth, The Crafts Store, CA, 95014

...

我们希望把它变成这个样子：

Bill Jones,CA 95011,HI-TEK Corporation

Sharon Lee Smith,CA 95012,Design Works Incorporated

B. Amos,CA 95013,Hill Street Cafe

Alexander Weatherworth,CA 95014,The Crafts Store

...

我们将用两个正则表达式来解决这个问题。第一个移动列和合并列，第二个用来去掉空格。

下面就是第一个替换命令：

:%s/$[^,]*$,$[^,]*$,$[^,]*$,$.*$/\1,\3 \4,\2/

这里的方法跟例1基本一样，第一个列（姓名）用这个表达式来匹配：$[^,]*$，即第一个逗号之前的所有字符，而姓名内容被用\1标记下来。公司名和州名缩写字段用同样的方法标记为\2和\3，而最后一个字段用$.*$来匹配（"匹配所有字符直到行末"）。替换部分则引用上面标记的那些内容来进行构造。

下面这个替换命令则用来去除空格：

:%s/[ \t]*,[ \t]*/,/g

我们还是分解来看：[ \t]匹配空格/制表符，[ \t]* 匹配0或多个空格/制表符，[ \t]*,匹配0或多个空格/制表符后面再加一个逗号，最后，[ \t]*,[ \t]*匹配0或多个空格/制表符接着一个逗号再接着0或多个空格/制表符。在替换部分，我们简单的我们找到的所有东西替换成一个逗号。这里我们使用了结尾的可选的g参数，这表示在每行中对所有匹配的串执行替换（而不是缺省的只替换第一个匹配串）。

例3

假设有一个多字符的片断重复出现，例如：

Billy tried really hard
Sally tried really really hard
Timmy tried really really really hard
Johnny tried really really really really hard

而你想把"really"、"really really"，以及任意数量连续出现的"really"字符串换成一个简单的"very"（simple is good!），那么以下命令：

:%s/$really $$really $*/very /

就会把上述的文本变成：

Billy tried very hard
Sally tried very hard
Timmy tried very hard
Johnny tried very hard

表达式$really $*匹配0或多个连续的"really "（注意结尾有个空格），而$really $$really $* 匹配1个或多个连续的"really "实例。

困难的例子（不可思议的象形文字）

Coming soon.

不同工具中的正则表达式

OK，你已经准备使用RE（regular expressions，正则表达式），但是你并准备使用vi。所以，在这里我们给出一些在其他工具中使用RE的例子。另外，我还会总结一下你在不同程序之间使用RE可能发现的区别。

当然，你也可以在Visual C++编辑器中使用RE。选择Edit->Replace，然后选择"Regular expression"选择框，Find What输入框对应上面介绍的vi命令:%s/pat1/pat2/g中的pat1部分，而Replace输入框对应pat2部分。但是，为了得到vi的执行范围和g选项，你要使用Replace All或者适当的手工Find Next and Replace（译者按：知道为啥有人骂微软弱智了吧，虽然VC中可以选中一个范围的文本，然后在其中执行替换，但是总之不够vi那么灵活和典雅）。

sed

Sed是Stream EDitor的缩写，是Unix下常用的基于文件和管道的编辑工具，可以在手册中得到关于sed的详细信息。

这里是一些有趣的sed脚本，假定我们正在处理一个叫做price.txt的文件。注意这些编辑并不会改变源文件，sed只是处理源文件的每一行并把结果显示在标准输出中（当然很容易使用重定向来定制）：

*sed脚本*		描述

`sed 's/^$/d' price.txt`		删除所有空行
*`sed 's/^[ \t]$/d' price.txt`**		删除所有只包含空格或者制表符的行
`sed 's/"//g' price.txt`		删除所有引号

awk

awk是一种编程语言，可以用来对文本数据进行复杂的分析和处理。可以在手册中得到关于awk的详细信息。这个古怪的名字是它作者们的姓的缩写（Aho，Weinberger和Kernighan）。

在Aho，Weinberger和Kernighan的书The AWK Programming Language中有很多很好的awk的例子，请不要让下面这些微不足道的脚本例子限制你对awk强大能力的理解。我们同样假定我们针对price.txt文件进行处理，跟sed一样，awk也只是把结果显示在终端上。

*awk脚本*		描述

`awk '$0 !~ /^$/' price.txt`		删除所有空行
`awk 'NF > 0' price.txt`		awk中一个更好的删除所有行的办法
`awk '$2 ~ /^[JT]/ {print $3}' price.txt`		打印所有第二个字段是'J'或者'T'打头的行中的第三个字段
`awk '$2 !~ /[Mm]isc/ {print $3 + $4}' price.txt`		针对所有第二个字段不包含'Misc'或者'misc'的行，打印第3和第4列的和（假定为数字）
*`awk '$3 !~ /^[0-9]+\.[0-9]$/ {print $0}' price.txt`**		打印所有第三个字段不是数字的行，这里数字是指`d.d`或者`d这样的形式，其中d`是0到9的任何数字
`awk '$2 ~ /John\|Fred/ {print $0}' price.txt`		如果第二个字段包含'John'或者'Fred'则打印整行

grep

grep是一个用来在一个或者多个文件或者输入流中使用RE进行查找的程序。它的name编程语言可以用来针对文件和管道进行处理。可以在手册中得到关于grep的完整信息。这个同样古怪的名字来源于vi的一个命令，g/re/p，意思是global regular expression print。

下面的例子中我们假定在文件phone.txt中包含以下的文本，——其格式是姓加一个逗号，然后是名，然后是一个制表符，然后是电话号码：

Francis, John           5-3871
Wong, Fred              4-4123
Jones, Thomas           1-4122
Salazar, Richard        5-2522

*grep命令*		描述

`grep '\t5-...1' phone.txt`		把所有电话号码以5开头以1结束的行打印出来，注意制表符是用`\t`表示的
*`grep '^S[^ ] R' phone.txt`**		打印所有姓以S打头和名以R打头的行
`grep '^[JW]' phone.txt`		打印所有姓开头是J或者W的行
`grep ', ....\t' phone.txt`		打印所有姓是4个字符的行，注意制表符是用`\t`表示的
`grep -v '^[JW]' phone.txt`		打印所有不以J或者W开头的行
`grep '^[M-Z]' phone.txt`		打印所有姓的开头是M到Z之间任一字符的行
*`grep '^[M-Z].[12]' phone.txt`**		打印所有姓的开头是M到Z之间任一字符，并且点号号码结尾是1或者2的行

egrep

egrep是grep的一个扩展版本，它在它的正则表达式中支持更多的元字符。下面的例子中我们假定在文件phone.txt中包含以下的文本，——其格式是姓加一个逗号，然后是名，然后是一个制表符，然后是电话号码：

Francis, John 5-3871

Wong, Fred 4-4123

Jones, Thomas 1-4122

Salazar, Richard 5-2522

*egrep command*		*Description*

`egrep '(John\|Fred)' phone.txt`		打印所有包含名字John或者Fred的行
`egrep 'John\|22$\|^W' phone.txt`		打印所有包含John 或者以22结束或者以W的行
`egrep 'net(work)?s' report.txt`		从report.txt中找到所有包含networks或者nets的行

正则表达式语法支持情况

命令或环境	`.`	`[ ]`	`^`	`$`	``	`\{ \}`	`?`	`+`	`\|`	`( )`
vi	X	X	X	X	X
Visual C++	X	X	X	X	X
awk	X	X	X	X			X	X	X	X
sed	X	X	X	X	X	X
Tcl	X	X	X	X	X		X	X	X	X
ex	X	X	X	X	X	X
grep	X	X	X	X	X	X
egrep	X	X	X	X	X		X	X	X	X
fgrep	X	X	X	X	X
perl	X	X	X	X	X		X	X	X	X

vi替换命令简介

Vi的替换命令：

:

range

s/

pat1

/

pat2

/g

其中

:

range

10,20

.,$

.+2,$-5

s 表示其后是一个替换命令。

pat1 这是要查找的一个正则表达式，这篇文章中有一大堆例子。

pat2

g 可选标志，带这个标志表示替换将针对行中每个匹配的串进行，否则则只替换行中第一个匹配串。

网上有很多vi的在线手册，你可以访问他们以获得更加完整的信息。

@王一伟 2007-04-10 09:59 发表评论

dumpbin.exe调试命令

@王一伟 — Mon, 02 Apr 2007 01:31:00 GMT

在使用VC时，可以用DUMPBIN。EXE来得到某个DLL中所输出的符号的清单。如下面的

命令：dumpbin -exports Cmpnt1.dll
如：

C:\WINDOWS\system32>dumpbin -exports msgsvc.dll
Microsoft (R) COFF Binary File Dumper Version 6.00.8447
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.

Dump of file msgsvc.dll

File Type: DLL

Section contains the following exports for msgsvc.dll

           0 characteristics
    41107F60 time date stamp Wed Aug 04 14:17:04 2004
        0.00 version
           1 ordinal base
           2 number of functions
           2 number of names

ordinal hint RVA name

1 0 00004ABF ServiceMain
2 1 00004595 SvchostPushServiceGlobals

Summary

        1000 .data
        1000 .reloc
        1000 .rsrc
        8000 .text

C:\>dumpbin
Microsoft (R) COFF Binary File Dumper Version 6.00.844
Copyright (C) Microsoft Corp 1992-1998. All rights res

usage: DUMPBIN [options] [files]

options:

      /ALL
      /ARCH
      /ARCHIVEMEMBERS
      /DEPENDENTS
      /DIRECTIVES
      /DISASM
      /EXPORTS
      /FPO
      /HEADERS
      /IMPORTS
      /LINENUMBERS
      /LINKERMEMBER[:{1|2}]
      /LOADCONFIG
      /OUT:filename
      /PDATA
      /RAWDATA[:{NONE|BYTES|SHORTS|LONGS}[,#]]
      /RELOCATIONS
      /SECTION:name
      /SUMMARY
      /SYMBOLS

若要运行 DUMPBIN，请使用下列语法：

DUMPBIN [options] files...

指定一个或多个二进制文件，以及控制信息所需的任何选项。DUMPBIN 将该信息显示到标准输出。可以将输出重定向到文件，或者使用 /OUT 选项为输出指定文件名。

当在文件上运行 DUMPBIN 但未指定选项时，DUMPBIN 显示 /SUMMARY 输出。

当键入命令 dumpbin 但没有任何其他命令行输入时，DUMPBIN 显示汇总其选项的用法语句。

DUMPBIN 选项

/ALL

此选项显示除代码反汇编外的所有可用信息。使用 /DISASM 显示反汇编。可以与 /ALL 一起使用 /RAWDATA:NONE 来省略文件的原始二进制详细资料。

只有 /HEADERS DUMPBIN 选项可用于由 /GL 编译器选项产生的文件。

/ARCHIVEMEMBERS

此选项显示有关库成员对象的最少信息。

只有 /HEADERS DUMPBIN 选项可用于由 /GL 编译器选项产生的文件。

/CLRHEADER file

此处：

file: 用 /clr 生成的图像文件。

备注

CLRHEADER 显示有关在任何托管程序中使用的 .NET 头的信息。输出显示 .NET 头及其中各节的位置和大小（以字节计）。

File Format Spec.doc 描述 .NET 头中的信息。NET SDK 将 File Format Spec.doc 安装在 Tools Developers Guide 目录中。

只有 /HEADERS DUMPBIN 选项可用于由 /GL 编译器选项产生的文件。

/DIRECTIVES

此选项转储图像中由编译器生成的 .directive 节。

只有 /HEADERS DUMPBIN 选项可用于由 /GL 编译器选项产生的文件。

/DEPENDENTS

转储图像从中导入函数的 DLL 的名称。不要转储导入函数名。

只有 /HEADERS DUMPBIN 选项可用于由 /GL 编译器选项产生的文件。

/DISASM

此选项显示代码段的反汇编，如果出现在文件中则使用符号。

只有 /HEADERS DUMPBIN 选项可用于由 /GL 编译器选项产生的文件。

/EXPORTS

此选项显示从可执行文件或 DLL 导出的所有定义。

只有 /HEADERS DUMPBIN 选项可用于由 /GL 编译器选项产生的文件。

/FPO

此选项显示框架指针优化 (FPO) 记录。

只有 /HEADERS DUMPBIN 选项可用于由 /GL 编译器选项产生的文件。

/HEADERS

此选项显示文件头和每节的头。当用于库时，显示每个成员对象的头。

只有 /HEADERS DUMPBIN 选项可用于由 /GL 编译器选项产生的文件。

/IMPORTS[:file]

此选项显示导入到可执行文件或 DLL 的 DLL 列表（静态链接的和延迟加载）和上述每个 DLL 的各个导入。

可选 file 规范允许指定仅显示某个 DLL 的导入。例如：

dumpbin /IMPORTS:msvcrt.dll

此选项显示的输出与 /EXPORTS 输出相似。

只有 /HEADERS DUMPBIN 选项可用于由 /GL 编译器选项产生的文件。

/LINENUMBERS

此选项显示 COFF 行号。如果对象文件是用程序数据库 (/Zi)、C7 兼容 (/Z7) 或仅限行号 (/Zd) 编译的，则它包含行号。如果可执行文件或 DLL 是与生成调试信息 (/DEBUG) 链接的，则它包含 COFF 行号。

只有 /HEADERS DUMPBIN 选项可用于由 /GL 编译器选项产生的文件。

/LINKERMEMBER[:{1|2}]

此选项显示库中定义的公共符号。指定参数 1 将按对象顺序显示符号及其偏移量。指定参数 2 将显示对象的偏移量和索引号，然后按字母顺序列出这些符号及每个符号的对象索引。若要两个输出都获得，指定不带数字参数的 /LINKERMEMBER。

只有 /HEADERS DUMPBIN 选项可用于由 /GL 编译器选项产生的文件。

/LOADCONFIG

此选项转储 IMAGE_LOAD_CONFIG_DIRECTORY 结构，此结构是由 Windows NT 加载程序使用并在 WINNT.H 中定义的可选结构。

只有 /HEADERS DUMPBIN 选项可用于由 /GL 编译器选项产生的文件。

/OUT:filename

此选项指定输出的 filename。默认情况下，DUMPBIN 将信息显示到标准输出。

只有 /HEADERS DUMPBIN 选项可用于由 /GL 编译器选项产生的文件。

/PDBPATH[:VERBOSE] filename

此处：

filename: 要为其查找匹配 .pdb 文件的 .dll 或 .exe 文件名。
VERBOSE（可选）: 报告曾尝试在其中定位 .pdb 文件的所有目录。

备注

/PDBPATH 将沿调试器搜索 .pdb 文件的同一路径搜索计算机，并将报告哪些 .pdb 文件（若有）和 filename 中指定的文件相对应。

使用 Visual Studio 调试器时可能会遇到问题，这是因为调试器对调试文件的不同版本使用 .pdb 文件。

/PDBPATH 将沿下列路径搜索 .pdb 文件：

检查可执行文件驻留的位置。
检查写入可执行文件的 PDB 的位置。这通常是图像被链接时的位置。
沿 Visual Studio IDE 中配置的搜索路径检查。
沿 _NT_SYMBOL_PATH 和 _NT_ALT_SYMBOL_PATH 环境变量中的路径检查。
在 Windows 目录中检查。

/PDATA

仅用于 RISC 处理器。

此选项从图像或对象转储异常表 (.pdata)。

只有 /HEADERS DUMPBIN 选项可用于由 /GL 编译器选项产生的文件。

/RAWDATA[:{1|2|4|8|NONE[,number]]

此选项显示文件中每节的原始内容。参数控制显示格式，如下所示：

参数	结果
1	默认值。内容以十六进制字节显示，如果内容具有打印的表示形式，则还显示为 ASCII 字符。
2	内容显示为十六进制的 2 字节值。
4	内容显示为十六进制的 4 字节值。
8	内容显示为十六进制的 8 字节值。
NONE	取消显示原始数据。此参数对控制 /ALL 输出很有用。
Number	显示的行被设置为每行具有 number 个值的宽度。

只有 /HEADERS DUMPBIN 选项可用于由 /GL 编译器选项产生的文件。

/RELOCATIONS

此选项显示对象或图像中的任何重定位。

只有 /HEADERS DUMPBIN 选项可用于由 /GL 编译器选项产生的文件。

/SECTION:section

此选项限制与指定的 section 有关的信息的输出。

只有 /HEADERS DUMPBIN 选项可用于由 /GL 编译器选项产生的文件。

/SUMMARY

此选项显示有关节的最少信息（包括总大小）。如果未指定其他选项，则此选项为默认值。

只有 /HEADERS DUMPBIN 选项可用于由 /GL 编译器选项产生的文件。

/SYMBOLS

此选项显示 COFF 符号表。符号表存在于所有对象文件中。而对于图像文件，只有当它是与 /DEBUG 链接的时，它才包含 COFF 符号表。

下面是关于 /SYMBOLS 输出的说明。通过查阅 winnt.h（IMAGE_SYMBOL 和 IMAGE_AUX_SYMBOL）或 COFF 文档，可找到有关 /SYMBOLS 输出含义的附加信息。

假设有下列示例转储：

Dump of file main.obj File Type: COFF OBJECT COFF SYMBOL TABLE 000 00000000 DEBUG notype Filename | .file main.cpp 002 000B1FDB ABS notype Static | @comp.id 003 00000000 SECT1 notype Static | .drectve Section length 26, #relocs 0, #linenums 0, checksum 722C964F 005 00000000 SECT2 notype Static | .text Section length 23, #relocs 1, #linenums 0, checksum 459FF65F, selection 1 (pick no duplicates) 007 00000000 SECT2 notype () External | _main 008 00000000 UNDEF notype () External | ?MyDump@@YAXXZ (void __cdecl MyDump(void)) String Table Size = 0x10 bytes Summary 26 .drectve 23 .text

对于以符号号码开头的行，下列说明描述了含有与用户相关的信息的列：

开头的 3 位数字是符号索引/号码。
如果第三列包含 SECTx，则符号在对象文件的那一节中定义。但如果出现 UNDEF，则它不在那个对象中定义并且必须在其他地方被解析。
第五列 (Static, External) 说明符号是否只在那个对象的内部可见，或者是否是公共的（外部可见）。静态符号 _sym 不会链接到公共符号 _sym；这些符号是名为 _sym 的函数的两种不同实例。

编号行中的最后一列是符号名（修饰名和未修饰名）。

只有 /HEADERS DUMPBIN 选项可用于由 /GL 编译器选项产生的文件。

/UNWINDINFO

在程序图像（例如 exe 和 dll）中转储结构化异常处理 (SEH) 表的展开描述符。/UNWINDINFO 仅适用于 IA64 图像。

只有 /HEADERS DUMPBIN 选项可用于由 /GL 编译器选项产生的文件。

@王一伟 2007-04-02 09:31 发表评论

关于封装中virtual的消耗问题

@王一伟 — Fri, 30 Mar 2007 18:44:00 GMT

晚上翻了翻《Inside th C++ object Model》

里面在讨论C和C++定义Point3d类型，C++加封装后的布局成本提高了多少。

作者分析来分析去，最后把C++在布局和存取时间上主要的额外负担是有virtual引起的

包括 virtual function 和 virtual base class .

书上就几句话，没太说清楚原因，各位路过多多指教啊：）

@王一伟 2007-03-31 02:44 发表评论

位运算

@王一伟 — Thu, 29 Mar 2007 04:35:00 GMT

位运算 (自己最近用的多做个复习记录)

　　前面介绍的各种运算都是以字节作为最基本位进行的。但在很多系统程序中常要求在位(bit)一级进行运算或处理。C语言提供了位运算的功能，这使得C语言也能像汇编语言一样用来编写系统程序。

　　一、位运算符C语言提供了六种位运算符：

　　 & 按位与
　　 | 按位或
　　 ^ 按位异或
　　 ~ 取反
　　 << 左移
　　 >> 右移

　　 1. 按位与运算按位与运算符"&"是双目运算符。其功能是参与运算的两数各对应的二进位相与。只有对应的两个二进位均为1时，结果位才为1 ，否则为0。参与运算的数以补码方式出现。

　　例如：9&5可写算式如下： 00001001 (9的二进制补码)&00000101 (5的二进制补码)　00000001 (1的二进制补码)可见9&5=1。

　　按位与运算通常用来对某些位清0或保留某些位。例如把a 的高八位清 0 ，保留低八位，可作 a&255 运算 ( 255 的二进制数为0000000011111111)。

main(){
　 int a=9,b=5,c;
　 c=a&b;
　 printf("a=%d\nb=%d\nc=%d\n",a,b,c);
}

　　 2. 按位或运算按位或运算符“|”是双目运算符。其功能是参与运算的两数各对应的二进位相或。只要对应的二个二进位有一个为1时，结果位就为1。参与运算的两个数均以补码出现。

　　例如：9|5可写算式如下：

00001001|00000101
00001101 (十进制为13)可见9|5=13
main(){
　 int a=9,b=5,c;
　 c=a|b;
　 printf("a=%d\nb=%d\nc=%d\n",a,b,c);
}

　　 3. 按位异或运算按位异或运算符“^”是双目运算符。其功能是参与运算的两数各对应的二进位相异或，当两对应的二进位相异时，结果为1。参与运算数仍以补码出现，例如9^5可写成算式如下：

00001001^00000101 00001100 (十进制为12)
main(){
　 int a=9;
　 a=a^15;
　 printf("a=%d\n",a);
}

　　 4. 求反运算求反运算符～为单目运算符，具有右结合性。其功能是对参与运算的数的各二进位按位求反。例如～9的运算为： ~(0000000000001001)结果为：1111111111110110

　　 5. 左移运算左移运算符“<<”是双目运算符。其功能把“<< ”左边的运算数的各二进位全部左移若干位，由“<<”右边的数指定移动的位数，

　　高位丢弃，低位补0。例如： a<<4 指把a的各二进位向左移动4位。如a=00000011(十进制3)，左移4位后为00110000(十进制48)。6. 右移运算右移运算符“>>”是双目运算符。其功能是把“>> ”左边的运算数的各二进位全部右移若干位，“>>”右边的数指定移动的位数。

　　例如：设 a=15，a>>2　表示把000001111右移为00000011(十进制3)。应该说明的是，对于有符号数，在右移时，符号位将随同移动。当为正数时，最高位补0，而为负数时，符号位为1，最高位是补0或是补1 取决于编译系统的规定。Turbo C和很多系统规定为补1。

main(){
　 unsigned a,b;
　 printf("input a number: ");
　 scanf("%d",&a);
　 b=a>>5;
　 b=b&15;
　 printf("a=%d\tb=%d\n",a,b);
}

　　请再看一例!

main(){
　 char a='a',b='b';
　 int p,c,d;
　 p=a;
　 p=(p<<8)|b;
　 d=p&0xff;
　 c=(p&0xff00)>>8;
　 printf("a=%d\nb=%d\nc=%d\nd=%d\n",a,b,c,d);
}

@王一伟 2007-03-29 12:35 发表评论

vc中的数据类型

@王一伟 — Sun, 25 Mar 2007 15:59:00 GMT

vc中的数据类型

1 、CString to char *
// 经过类型强制转换，可以将CString类型转换成char*，例如：
CString cStr = " Hello,world! " ;
char * zStr = ( char * )(LPCTSTR)cStr;
// cstring与int转换
int StringToInt(CString source)
{
     char * buff = source.GetBuffer(source.GetLength());
     int i = atoi(buff);
    source.ReleaseBuffer();
     return i;
}

2 、 char * to CString
// char*类型可以直接给CString，完成自动转换，例如：
char * zStr = " Hello,world! " ;
CString cStr = zStr;

3 、CString to LPCSTR
// 将CString转换成LPCSTR，需要获得CString的长度CString cStr = _T("Hello,world!");
int nLen = cStr.GetLength();
LPCSTR lpszBuf = cStr.GetBuffer(nLen);

4 、CString to LPSTR
// 这个和第3个技巧是一样的，例如：
CString cStr = _T( " Hello,world! " );
int nLen = str.GetLength();
LPSTR lpszBuf = str.GetBuffer(nLen);

在vc中关于类型的转换比较麻烦，新手开发vc程序遇到的第一个问题往往和这个有关。
近日从网上以及自己的经验,搜索了一些相关资料。
PCXSTR，如果不是在 Unicode 下，PCXSTR 与 const char* 是相同的;
CString 作为指向字符的非常数指针来直接访问时，请使用 GetBuffer 和 ReleaseBuffer 成员函数。
使用 AllocSysString 和 SetSysString 成员函数来分配和设置用于自动化（以前称为 OLE 自动化）中的 BSTR 对象。
一个 CString 对象可存储多达 INT_MAX (2,147,483,647) 个字符。TCHAR 数据类型用来获取或设置 CString 对象中的单个字符。与字符数组不同，CString 类具有内置内存分配能力。

从 MFC 4.0 版本开始，当复制 CString 对象时，MFC 增加引用计数而不是复制数据。这使得按值传递参数和按值返回 CString 对象更为高效。这些操作将调用复制构造函数，有时甚至不只一次。增加引用计数会减少这些普通操作的系统开销，并且使人更愿意使用 CString。

随着每个副本的销毁，原对象中的引用计数也会相应减少。直到原 CString 对象的引用计数减少到零时才会销毁该对象。

可使用 CString 成员函数 LockBuffer 和 UnlockBuffer 来禁用或启用引用计数。

@王一伟 2007-03-25 23:59 发表评论

请达人提示一下

@王一伟 — Thu, 22 Mar 2007 03:58:00 GMT

最近公司让我写个小模块，完成序列化的底层设计

现在XMLFormatter已经完成，要继续完成BinaryFormatter

在网上搜索了一下，到处都是关于framework里面Formatter的使用的说明，没有原理方面的介绍，实在不知道该如何下手

基本就是要实现将类转换成二进制信息序列化进文件里面

String str;

BinaryFormatter xml;

File file;
xml.Serialize(&file,&str);

呵呵还有反序列化省略了

@王一伟 2007-03-22 11:58 发表评论

C++中文件流的操作方法

@王一伟 — Wed, 21 Mar 2007 08:12:00 GMT

hehe,做点记载转的

在C++中，有一个stream这个类，所有的I/O都以这个“流”类为基础的，包括我们要认识的文件I/O，stream这个类有两个重要的运算符：

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

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='n')；这种形式把字符读入由 buf 指向的数组，直到读入了 num 个字符或遇到了由 delim 指定的字符，如果没使用 delim 这个参数，将使用缺省值换行符'n'。例如：

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个字节

@王一伟 2007-03-21 16:12 发表评论

MultiByteToWideChar和WideCharToMultiByte用法详解

@王一伟 — Wed, 21 Mar 2007 04:01:00 GMT

MultiByteToWideChar和WideCharToMultiByte用法详解

//========================================================================
//TITLE:
//    MultiByteToWideChar和WideCharToMultiByte用法详解
//AUTHOR:
//    norains
//DATE:
//    第一版:Monday 25-December -2006
//    增补版:Wednesday 27-December -2006
//    修订版:Wednesday 14-March-2007 (修正之前的错误例子)
//Environment:
// EVC4.0 + Standard SDK
//========================================================================

1.使用方法详解

在本文开始之处,先简要地说一下何为短字符和宽字符.
所谓的短字符,就是用8bit来表示的字符,典型的应用是ASCII码.而宽字符,顾名思义,就是用16bit表示的字符,典型的有UNICODE.关于windows下的ASCII和UNICODE的更多信息,可以参考这两本经典著作:《windows 程序设计》,《windows 核心编程》.这两本书关于这两种字符都有比较详细的解说.

宽字符转换为多个短字符是一个难点,不过我们只要掌握到其中的要领,便可如鱼得水.
好吧,那就让我们开始吧.

这个是我们需要转化的多字节字符串:
char sText[20] = {"多字节字符串!OK!"};

我们需要知道转化后的宽字符需要多少个数组空间.虽然在这个里程里面,我们可以直接定义一个20*2宽字符的数组,并且事实上将运行得非常轻松愉快.但假如多字节字符串更多,达到上千个乃至上万个,我们将会发现其中浪费的内存将会越来越多.所以以多字节字符的个数的两倍作为宽字符数组下标的声明绝对不是一个好主意.
所幸,我们能够确知所需要的数组空间.
我们只需要将MultiByteToWideChar()的第四个形参设为-1,即可返回所需的短字符数组空间的个数:
DWORD dwNum = MultiByteToWideChar (CP_ACP, 0, sText, -1, NULL, 0);

接下来,我们只需要分配响应的数组空间:
wchar_t *pwText;
pwText = new wchar_t[dwNum];
if(!pwText)
{
   delete []pwText;
}

接着,我们就可以着手进行转换了.在这里以转换成ASCII码做为例子:
MultiByteToWideChar (CP_ACP, 0, psText, -1, sText, dwSize);

最后,使用完毕当然要记得释放占用的内存:
delete []psText;

同理,宽字符转为多字节字符的代码如下:
wchar_t wText[20] = {L"宽字符转换实例!OK!"};
DWORD dwNum = WideCharToMultiByte(CP_OEMCP,NULL,lpcwszStr,-1,NULL,0,NULL,FALSE);
char *psText;
psText = new char[dwNum];
if(!psText)
{
   delete []psText;
}
WideCharToMultiByte (CP_OEMCP,NULL,lpcwszStr,-1,psText,dwNum,NULL,FALSE);
delete []psText;

   如果之前我们已经分配好空间,并且由于字符串较短,可以不理会浪费的空间,仅仅只是想简单地将短字符和宽字符相互转换,那有没有什么简便的方法呢?
   WIN32 API里没有符合这种要求的函数,但我们可以自己进行封装:

//-------------------------------------------------------------------------------------
//Description:
// This function maps a character string to a wide-character (Unicode) string
//
//Parameters:
// lpcszStr: [in] Pointer to the character string to be converted
// lpwszStr: [out] Pointer to a buffer that receives the translated string.
// dwSize: [in] Size of the buffer
//
//Return Values:
// TRUE: Succeed
// FALSE: Failed
//
//Example:
// MByteToWChar(szA,szW,sizeof(szW)/sizeof(szW[0]));
//---------------------------------------------------------------------------------------
BOOL MByteToWChar(LPCSTR lpcszStr, LPWSTR lpwszStr, DWORD dwSize)
{
    // Get the required size of the buffer that receives the Unicode
    // string.
    DWORD dwMinSize;
    dwMinSize = MultiByteToWideChar (CP_ACP, 0, lpcszStr, -1, NULL, 0);

    if(dwSize < dwMinSize)
    {
     return FALSE;
    }


    // Convert headers from ASCII to Unicode.
    MultiByteToWideChar (CP_ACP, 0, lpcszStr, -1, lpwszStr, dwMinSize);
    return TRUE;
}

//-------------------------------------------------------------------------------------
//Description:
// This function maps a wide-character string to a new character string
//
//Parameters:
// lpcwszStr: [in] Pointer to the character string to be converted
// lpszStr: [out] Pointer to a buffer that receives the translated string.
// dwSize: [in] Size of the buffer
//
//Return Values:
// TRUE: Succeed
// FALSE: Failed
//
//Example:
// MByteToWChar(szW,szA,sizeof(szA)/sizeof(szA[0]));
//---------------------------------------------------------------------------------------
BOOL WCharToMByte(LPCWSTR lpcwszStr, LPSTR lpszStr, DWORD dwSize)
{
   DWORD dwMinSize;
   dwMinSize = WideCharToMultiByte(CP_OEMCP,NULL,lpcwszStr,-1,NULL,0,NULL,FALSE);
   if(dwSize < dwMinSize)
   {
    return FALSE;
   }
   WideCharToMultiByte(CP_OEMCP,NULL,lpcwszStr,-1,lpszStr,dwSize,NULL,FALSE);
   return TRUE;
}

使用方法也很简单,示例如下:
wchar_t wText[10] = {L"函数示例"};
char sText[20]= {0};
WCharToMByte(wText,sText,sizeof(sText)/sizeof(sText[0]));
MByteToWChar(sText,wText,sizeof(wText)/sizeof(wText[0]));

这两个函数的缺点在于无法动态分配内存,在转换很长的字符串时可能会浪费较多内存空间;优点是,在不考虑浪费空间的情况下转换较短字符串非常方便.

2.MultiByteToWideChar()函数乱码的问题

有的朋友可能已经发现,在标准的WinCE4.2或WinCE5.0 SDK模拟器下,这个函数都无法正常工作,其转换之后的字符全是乱码.及时更改MultiByteToWideChar()参数也依然如此.
不过这个不是代码问题,其结症在于所定制的操作系统.如果我们定制的操作系统默认语言不是中文,也会出现这种情况.由于标准的SDK默认语言为英文,所以肯定会出现这个问题.而这个问题的解决,不能在简单地更改控制面板的"区域选项"的"默认语言",而是要在系统定制的时候,选择默认语言为"中文".
系统定制时选择默认语言的位置于:
Platform -> Setting... -> locale -> default language ,选择"中文",然后编译即可.

@王一伟 2007-03-21 12:01 发表评论

关于gcnew （转）

@王一伟 — Tue, 20 Mar 2007 04:52:00 GMT

关于gcnew (转)

C++/CLI中使用gcnew关键字表示在托管堆上分配内存，并且为了与以前的指针区分，用^来替换* ，就语义上来说他们的区别大致如下:

　　1. gcnew返回的是一个句柄(Handle)，而new返回的是实际的内存地址.

　　2. gcnew创建的对象由虚拟机托管，而new创建的对象必须自己来管理和释放.

　　当然，从程序员的角度来说，管它是句柄还是什么其他的东西，总跑不掉是对某块内存地址的引用，实际上我们都可以理解成指针.下面我们就写一段代码来测试一下好了.

using namespace System;

ref class Foo

{

public:

Foo()

{

System::Console::WriteLine("Foo::Foo");

}

~Foo()

{

System::Console::WriteLine("Foo::~Foo");

}

public:

int m_iValue;

};

int _tmain()

{

int* pInt = new int;

int^ rInt = gcnew int;

Foo^ rFoo = gcnew Foo;

delete rFoo;

delete rInt;

delete pInt;

}

　　我把调试的时候JIT编译的汇编代码择录了部分如下显示（请注意红色部分）：

int* pInt = new int;

0000004c mov ecx，4

00000051 call dword ptr ds:[03B51554h]

00000057 mov esi，eax

00000059 mov dword ptr [esp+18h]，esi

int^ rInt = gcnew int;

0000005d mov ecx，788EF9D8h

00000062 call FCFAF66C

00000067 mov esi，eax

00000069 mov dword ptr [esi+4]，0

00000070 mov edi，esi

Foo^ rFoo = gcnew Foo;

00000072 mov ecx，3B51768h

00000077 call FCFAF66C

0000007c mov esi，eax

0000007e mov ecx，esi

00000080 call dword ptr ds:[03B517ACh]

00000086 mov dword ptr [esp+1Ch]，esi

delete rFoo;

0000008a mov ebx，dword ptr [esp+1Ch]

0000008e test ebx，ebx

00000090 je 000000A4

00000092 mov ecx，ebx

00000094 call dword ptr ds:[03FD0028h]

0000009a mov dword ptr [esp+14h]，0

000000a2 jmp 000000AC

000000a4 mov dword ptr [esp+14h]，0

delete rInt;

000000ac mov edx，edi

000000ae mov ecx，788F747Ch

000000b3 call FC8D20FD

000000b8 mov ebp，eax

000000ba test ebp，ebp

000000bc je 000000D0

000000be mov ecx，ebp

000000c0 call dword ptr ds:[03FD0020h]

000000c6 mov dword ptr [esp+10h]，0

000000ce jmp 000000D8

000000d0 mov dword ptr [esp+10h]，0

delete pInt;

000000d8 mov ecx，dword ptr [esp+18h]

000000dc call dword ptr ds:[03B51540h]

　　我们先看分配内存这部分的代码

　　1．调用new方式分配

int* pInt = new int;

0000004c mov ecx，4

00000051 call dword ptr ds:[03B51554h]

　　可以看到，和以前在vc6中一样，分配内存的步骤如下：

　　1．首先把sizeof(int) = 4 放到ecx中

　　2．调用operator new 去分配4个字节

　　3．调用构造函数等等......(这里不是我们的重点)

　　成功分配后，会把返回地址放在eax中。

　　2．调用gcnew方式分配

int^ rInt = gcnew int;

0000005d mov ecx，788EF9D8h

00000062 call FCFAF66C

。。。

Foo^ rFoo = gcnew Foo;

00000072 mov ecx，3B51768h

00000077 call FCFAF66C

　　可以看到gcnew也是通过把一个参数放到ecx中，然后再调用一个函数来完成分配的操作，显然0x788EF9D8应该是一个地址，而不可能是一个数值。我们可以看到这里gcnew创建两个不同类型的变量，调用的函数地址却都是0xFCFAF66C，而存放到ecx中的两个地址就不一样。究竟这几个地址代表什么呢？

　　和new一样gcnew也是把返回地址放在eax中。我们直接从内存窗口看eax指向的内存块好了。Aha，看到了没有？

　　这次的eax = 0x00F73404 对应的内存块为

0x00F73404 d8 f9 8e 78 00 00 00 00 。。。

　　这个不就是 mov 到 ecx中的值么？再回忆昨天写的分析Object对象布局的文章，可以肯定这个就是 MethodTable地址了，对于这个int来说，后面的4个字节对应的就是存放它的RawData，比如如果你初始化为 4 那么内存对应的就变化为 d8 f9 8e 79 04 00 00 00

　　分析清楚存放到ecx中的是 MethodTable指针，我们再分析那个对应的call函数，从vm的代码可以看出，有三个全局函数用来根据MethodTable创建对象，同时MethodTable本身也提供一个成员函数Allocate()，只不过这个成员函数也是调用的下面的函数：

OBJECTREF AllocateObject( MethodTable *pMT )

OBJECTREF AllocateObjectSpecial( MethodTable *pMT )

OBJECTREF FastAllocateObject( MethodTable *pMT )

　　其中AllocateObject又是调用AllocateObjectSpecial来完成工作。那么我们调用的应该就是AllocateObject或者FastAllocateObject了。

　　在我们的例子里面两个call的地址都一样，但是你如果写下代码 double ^ pDouble = gcnew double;这个时候的地址是多少？它和int 的一样么？

　　目前我还没有仔细去研究这个地址到底对应的是该类型的MethodTable::Allocate()或是上面的这三个全局函数，如果对应MethodTable::Allocate()，那么2.0中应该有个MethodTable::FastAllocate()吧，否则应该就是对应的全局函数AllocateObject 以及FastAllocateObject了。过几天一定要抽空再好好研究一下。

　　下面看对应的delete函数。

delete pInt;

000000d8 mov ecx，dword ptr [esp+18h]

000000dc call dword ptr ds:[03B51540h]

比较简单，就是传入地址，然后调用operator delete来释放类存，会调用析构函数

　　对应的，释放gcnew创建的对象的代码如下：

delete rInt;

000000ac mov edx，edi

000000ae mov ecx，788F747Ch

000000b3 call FC8D20FD

　　这个也相对简单，它对应vm里面的一个函数：

void CallFinalizer(Thread* FinalizerThread， Object* fobj)

　　那么也就是

fobjà edx

FinalizerThread à ecx

Call CallFinalizer

　　但是，请注意！！！！！！！一个类包含析构函数和不包含析构函数，它对应的delete代码是不一样的，这点可以通过汇编代码比较得到，我这里就不多说了。

@王一伟 2007-03-20 12:52 发表评论

debug调试中，AssertValid和Dump 这两个函数怎么进行工作的？

@王一伟 — Wed, 07 Mar 2007 08:41:00 GMT

<转自csdn相关问题回复>

CObject::AssertValid 成员函数提供对对象内部状态的运行时检查。尽管从 CObject 派生类时不需要重写 AssertValid，但可以通过重写使您的类更安全可靠。AssertValid 应在对象的所有成员变量上执行断言，以验证它们包含有效值。例如，它应检查指针成员变量不为 NULL。

下面的示例显示如何声明 AssertValid 函数：
class CPerson : public CObject
{
protected:
CString m_strName;
float m_salary;
public:
#ifdef _DEBUG
virtual void AssertValid() const; // Override
#endif
// ...
};
当重写 AssertValid 时，在执行您自己的检查之前请调用 AssertValid 的基类版本。然后使用 ASSERT 宏检查您的派生类特有的成员，如下所示：

#ifdef _DEBUG
void CPerson::AssertValid() const
{
// call inherited AssertValid first
CObject::AssertValid();

// check CPerson members...
ASSERT( !m_strName.IsEmpty()); // Must have a name
ASSERT( m_salary > 0 ); // Must have an income
}
#endif
如果任何成员变量存储对象，则可以使用 ASSERT_VALID 宏测试它们的内部有效性（如果它们的类重写了 AssertValid）。

例如，考虑 CMyData 类，该类在其成员变量之一中存储了一个 CObList。CObList 变量 m_DataList 存储了一个 CPerson 对象的集合。CMyData 的简化声明如下所示：

class CMyData : public CObject
{
// Constructor and other members ...
protected:
CObList* m_pDataList;
// Other declarations ...
public:
#ifdef _DEBUG
virtual void AssertValid( ) const; // Override
#endif
// Etc. ...
};
CMyData 中重写的 AssertValid 如下所示：

#ifdef _DEBUG
void CMyData::AssertValid( ) const
{
// Call inherited AssertValid
CObject::AssertValid( );
// Check validity of CMyData members
ASSERT_VALID( m_pDataList );
// ...
}
#endif
CMyData 使用 AssertValid 机制测试其数据成员中存储的对象的有效性。CMyData 中重写的 AssertValid 为它自己的 m_pDataList 成员变量调用 ASSERT_VALID 宏。

因为 CObList 类也重写 AssertValid，所以有效性测试不在该级别停止。该重写对列表的内部状态执行附加有效性测试。因此，对 CMyData 对象的有效性测试将导致对存储的 CObList 列表对象内部状态的附加有效性测试。

再多进行一些操作，还可以添加对存储在列表中的 CPerson 对象的有效性测试。可以从 CObList 派生 CPersonList 类，并重写 AssertValid。在重写中可调用 CObject::AssertValid，然后循环访问列表，在列表中存储的每个 CPerson 对象上调用 AssertValid。本主题开始所示的 CPerson 类已重写了 AssertValid。

当为调试生成时，这是一种功能极强的机制。当接着为发布生成时，该机制自动关闭。

AssertValid 的限制
给定类的 AssertValid 函数的用户应注意该函数的限制。触发的断言指示对象一定有误，并且执行将暂停。但是，缺少断言只指示未找到任何问题，并不保证对象是好的。

当从 CObject 派生类时，在使用 DumpAllObjectsSince 将对象转储到“输出”窗口时，可以重写 Dump 成员函数以提供附加信息。

Dump 函数将对象的成员变量的文本化表示形式写入转储上下文 (CDumpContext)。转储上下文类似于 I/O 流。可以使用插入运算符 (<<) 向 CDumpContext 发送数据。

重写 Dump 函数时，应先调用 Dump 的基类版本以转储基类对象的内容。然后为派生类的每个成员变量输出文本化说明和值。

Dump 函数的声明如下所示：

class CPerson : public CObject
{
public:
#ifdef _DEBUG
virtual void Dump( CDumpContext& dc ) const;
#endif

CString m_firstName;
CString m_lastName;
// And so on...
};
由于对象转储只在调试程序时有意义，所以 Dump 函数的声明用 #ifdef _DEBUG / #endif 块括起来。

在下面的示例中，Dump 函数先为其基类调用 Dump 函数。然后，它将每个成员变量的简短说明与该成员的值一起写入诊断流。

#ifdef _DEBUG
void CPerson::Dump( CDumpContext& dc ) const
{
// Call the base class function first.
CObject::Dump( dc );

// Now do the stuff for our specific class.
dc << "last name: " << m_lastName << "\n"
<< "first name: " << m_firstName << "\n";
}
#endif
必须提供 CDumpContext 参数以指定转储输出的目的地。MFC 的“Debug”版本提供名为 afxDump 的预定义 CDumpContext 对象，它将输出发送到调试器。

CPerson* pMyPerson = new CPerson;
// Set some fields of the CPerson object.
//...
// Now dump the contents.
#ifdef _DEBUG
pMyPerson->Dump( afxDump );
#endif
在 MFC 程序中，可以使用 DumpAllObjectsSince 转储有关堆中尚未释放的所有对象的说明。DumpAllObjectsSince 转储自上个 CMemoryState::Checkpoint 以来分配的所有对象。如果未发生 Checkpoint 调用，则 DumpAllObjectsSince 将转储当前在内存中的所有对象和非对象。

注意必须先启用诊断跟踪，然后才能使用 MFC 对象转储。
注意程序退出时 MFC 将自动转储所有泄漏的对象，因此不必创建代码在该点转储对象。
以下代码通过比较两个内存状态来测试内存泄漏，并在检测到泄漏时转储所有对象：

if( diffMemState.Difference( oldMemState, newMemState ) )
{
TRACE( "Memory leaked!\n" );
diffMemState.DumpAllObjectsSince();
}
转储的内容如下所示：

Dumping objects ->

{5} strcore.cpp(80) : non-object block at $00A7521A, 9 bytes long
{4} strcore.cpp(80) : non-object block at $00A751F8, 5 bytes long
{3} strcore.cpp(80) : non-object block at $00A751D6, 6 bytes long
{2} a CPerson at $51A4

Last Name: Smith
First Name: Alan
Phone #: 581-0215

{1} strcore.cpp(80) : non-object block at $00A7516E, 25 bytes long
大多数行开始处的大括号中的数字指定对象的分配顺序。最近分配的对象具有最高编号，并显示在转储的顶部。

@王一伟 2007-03-07 16:41 发表评论

LPSTR LPCSTR LPWSTR LPCWSTR区别

@王一伟 — Wed, 07 Mar 2007 04:06:00 GMT

LPSTR 一个32位的指向字符串的指针
LPCSTR 一个32位的指向字符串常量的指针
LPWSTR 一个32位的指向unicode字符串的指针
LPCWSTR 个32位的指向unicode字符串常量的指针

前面的L代表LONG,P就是指针的意思,C就是constant的意思
W是wide的意思，STR就是string的意思

@王一伟 2007-03-07 12:06 发表评论

#if _MSC_VER > 1000

@王一伟 — Wed, 07 Mar 2007 03:25:00 GMT

自己对
#if _MSC_VER > 1000
#pragma once
#endif // _MSC_VER > 1000用法不清楚找些资料做些总结

当编译器版本号大于1000的时候，改.h文件只包含一次，是这样吗？

解析#pragma指令
在所有的预处理指令中，#Pragma 指令可能是最复杂的了，它的作用是设定编译器的状态或者是指示编译器完成一些特定的动作。#pragma指令对每个编译器给出了一个方法,在保持与C和C++语言完全兼容的情况下,给出主机或操作系统专有的特征。依据定义,编译指示是机器或操作系统专有的,且对于每个编译器都是不同的。
其格式一般为: #Pragma Para
其中Para 为参数，下面来看一些常用的参数。

(1)message 参数。 Message 参数是我最喜欢的一个参数，它能够在编译信息输出窗
口中输出相应的信息，这对于源代码信息的控制是非常重要的。其使用方法为：
#Pragma message(“消息文本”)
当编译器遇到这条指令时就在编译输出窗口中将消息文本打印出来。
当我们在程序中定义了许多宏来控制源代码版本的时候，我们自己有可能都会忘记有没有正确的设置这些宏，此时我们可以用这条指令在编译的时候就进行检查。假设我们希望判断自己有没有在源代码的什么地方定义了_X86这个宏可以用下面的方法
#ifdef _X86
#Pragma message(“_X86 macro activated!”)
#endif
当我们定义了_X86这个宏以后，应用程序在编译时就会在编译输出窗口里显示“_
X86 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关键字，可以帮我们连入一个库文件。

(8)#pragma pack()
我们知道在VC中，对于想结构体Struct这样的类型，VC采用8字节对齐的方式，如果我们不想使用8字节对齐（在网络变成中经常需要这样），我们可以在结构体前面加上
#pragma pack(1)
struct
{
......
}
#pragma pack()

@王一伟 2007-03-07 11:25 发表评论

MFC CButton封装的问题

@王一伟 — Mon, 05 Mar 2007 16:55:00 GMT

我现在想把CButton重新封装下,一开始就遇见了问题,希望大家帮忙指导下
////////////////////////////////////////TCButton.h
#ifndef TCButton_H_
#define TCButton_H_
class TCButton:public CButton
{
public:
//! Standard constructor.
TCButton();
//! Standard destructor.
virtual ~TCButton();
};
#endif

////////////////////////////////////////TCButton.cpp
#include "stdafx.h"
#include "TCButton.h"
TCButton::TCButton()
{
Create(_T("My button"), WS_CHILD|WS_VISIBLE|BS_PUSHBUTTON,CRect(0,0,40,20), this, 1);
}
TCButton::~TCButton()
{
}

现在我想在另外的Dailog中使用这个Button的话,我想实现

我想在堆内存中TCButton myButton;
然后再进行父窗口的指定myButton.SetParent(CWnd* pWnd);

这样的效果怎么做啊?

如果是new出来的好办,我可以引用带参数的构造函数,传入
Create(_T("My button"), WS_CHILD|WS_VISIBLE|BS_PUSHBUTTON,CRect(0,0,40,20), this, 1)的第3个参数CWnd* pParentCwnd
,但是如果我声明在.h文件中呢我不知道怎么做呵呵

希望能给点提示:)

@王一伟 2007-03-06 00:55 发表评论

女人们的友谊与男人们的友谊（轻松下）

@王一伟 — Fri, 02 Mar 2007 10:54:00 GMT

女人们的友谊：

一个女人有一晚没回家　　
隔天她跟老公说他睡在一个女性朋友那边　　
她老公打电话给她最好的10个朋友，没有一个知道这件事！

男人们的友谊：
一个男人有一晚没回家睡　　
隔天他跟老婆说他睡在一个兄弟那边　　
她老婆打电话给他最好的10个朋友，有八个好兄弟确定他老公睡在他们家...... 　　
还有2个说“他老公还在他那儿！”

某网友的回帖：昨完把此帖给我老婆看，没想到她兴致大发；立刻打电话给我朋友问我是否在他们那里．结果可想而知，再次论证了上诉观点！更离谱的是有一哥们竟然说我在他家喝醉了，正睡着呢，还问我老婆要不要喊我起来接电话？在挂了电话后，那哥们的电话马上打到我手机上，一接通没等我说话就大喊：在哪呢，快回家吧，你老婆找你呢！！！

@王一伟 2007-03-02 18:54 发表评论

friend随笔

@王一伟 — Wed, 28 Feb 2007 10:00:00 GMT

//////////////////////TestClass.h
#ifndef _TEST_H_
#define _TEST_H_

class TestClass2;
class TestClass1
{
private:
       int i;
public:
       TestClass1()
       {
              i = 10;
       }

void ChangePrivate(TestClass2& test,int change_i);

};

class TestClass2
{
private:
int i;
public:

       TestClass2()
       {
           i = 20;
       }

friend void TestClass1::ChangePrivate(TestClass2& test,int change_i);
};

#endif

///////////////////////////TestClass.cpp
#include "stdafx.h"
#include "TestClass.h"

void TestClass1::ChangePrivate(TestClass2& test,int change_i)
{
test.i = change_i;
}

/////////////////////Main.cpp
#include "TestClass.h"
using namespace std;

int _tmain(int argc, _TCHAR* argv[])
{

TestClass1 test1;
TestClass2 test2;

test1.ChangePrivate(test2,1);

       getchar();
       getchar();
       return 0;
}

现在我不明白的是TestClass.cpp里的
void TestClass1::ChangePrivate(TestClass2& test,int change_i)
{
test.i = change_i;
}
我如果放在TestClass.h里面就link错误，如果哪位仁兄能指导下不胜感激，错误提示如下：
Generating Code...
Linking...
TsetClass.obj : error LNK2005: "public: void __thiscall TestClass1::ChangePrivate(class TestClass2 &,int)" (?ChangePrivate@TestClass1@@QAEXAAVTestClass2@@H@Z) already defined in thinking test.obj
E:\随便\thinking test\Debug\thinking test.exe : fatal error LNK1169: one or more multiply defined symbols found
Build log was saved at "file://e:\随便\thinking test\thinking test\Debug\BuildLog.htm"
thinking test - 2 error(s), 0 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

@王一伟 2007-02-28 18:00 发表评论

空struct为何有大小？（求解释）

@王一伟 — Wed, 28 Feb 2007 08:34:00 GMT

struct A
{
int a;
int b;
int c;
};

struct B
{

};
int _tmain(int argc, _TCHAR* argv[])
{
cout<

cout<

getchar();
getchar();
return 0;
}

@王一伟 2007-02-28 16:34 发表评论

完美的C++：C++/CLI

@王一伟 — Sat, 10 Feb 2007 11:13:00 GMT

转自:CSDN 自己做记录大家不要砸砖头明年中旬研究这块

什么是C++/CLI呢？C++当然指的是Bjarne Stroustrup在BELL实验室发明的C++语言，它实现了运行时取得速度和尺寸最佳化的静态对象模型，然而它除了堆分配外不支持程序的动态修改，它准许无限地接近底层设备，但在程序运行过程中几乎无法操作活动类型，也无法操作与程序相关联的底层结构。Herb Sutter，C++/CLI的主要构造者之一，称C++是一门“混凝土”式的语言。

　　CLI指的是通用语言结构，一种支持动态组件编程模型的多重结构，在许多情况下，这代表了一个与C++对象模型完全颠倒了的模式。一个时实的软件层，有效地执行系统，在底层操作系统与程序之间运行。操作底层的设备受到一定的限制，操作执行程序中的活动类型及与程序相关联的下部结构得到了支持。反斜杠（/）代表C++和CLI的捆绑，这个捆绑带来的细节问题是本文主要讨论的问题。

　　所以，“什么是C++/CLI”问题的最初、最接近答案是：它是静态C++对象模型到CLI的动态组件对象编程模型的捆绑。简而言之，它就是你如何用C++在.NET中编程，而不是C#或Visual Basic.NET。象C#和CLI本身一样，C++/CLI正在ECMA（欧洲计算机制造商协会）主持下进行标准化，以最终符合ISO标准。

　　实时通用语言（CLR）是CLI的微软版本，它非常适用于微软的Windows操作系统，相似地，Visual C++2005是C++/CLI的实现。

　　作为第二个近似的答案，我认为C++/CLI是.NET编程模式与C++的结合，正如以前将模板与C++结合起来产生的泛型编程。所有这种结合中，企业所拥有的C++的投资以及开发人员使用C++的经验将得到保存，而这恰恰是使用C++/CLI进行开发的重要基础。

　　阅读导航

　　学习C++/CLI的方法
　　在设计C++/CLI语言中涉及三个方面问题，这同样贯彻于所有的其他程序开发语言：一是语言级的语法向底层通用类型系统（简称CTS）的映射；二是向程序开发人员提供的CLI的底层细节结构的级别选择；三是超越CLI的直接支持，提供额外的功能性函数的选择。

　　从C++/CLI到CTS的映射？
　　使用C++/CLI编程时间了解底层的CTS非常重要。CTS包括以下三种常用类的类型：

　　1、多态引用类型，这正是对于所有继承类所要使用的。

　　2、非多态值类型，这用于实时高效的具体类型，例如数值类型。

　　3、抽象的接口类型，这用于定义一个操作集，也可以用于实现接口的引用或值类型集合。

　　CLI的细节
　　设计一个CLI语言时第二个必须要考虑的问题是将CLI的底层执行模式融入到语言的细节级别。这种语言用于解决什么问题？这种语言是否有必须的工具来解决这些问题？这种语言可能吸引什么样的程序开发人员？

　　存在的问题
　　在垃圾收集器扫描紧缩状态下，位于托管堆上的任何对象非常可能面对重新定位问题。指向对象的指针可以实时跟踪并修改。开发人员不能自己手动跟踪，所以，如果你获许取得一个可能位于托管堆上的值类型的地址时，除了本地指针外，还需要有一个跟踪形态的指针。

　　额外增加的功能
　　在垃圾收集器扫描紧缩状态下，位于托管堆上的任何对象非常可能面对重新定位问题。指向对象的指针可以实时跟踪并修改。开发人员不能自己手动跟踪，所以，如果你获许取得一个可能位于托管堆上的值类型的地址时，除了本地指针外，还需要有一个跟踪形态的指针。

　　小结

　　C++/CLI代表托管与本地编程的结合，这种综合已经通过元级相对独立但又相互平等地组件和二进制元素得到了完成，包括混合模式（本地和CTS类型的元级混合，还有一个本地及CLI对象文件的二进制混合），纯模式（本地和CTS类型的源代码级混合，所有的都被编译为CLI对象文件），本地分类（可以通过一个特定的打包类来保持CTS类型），和CTS分类（可以保持本地类型为指针）。

　　当然，C++/CLI开发人员也可以单独使用CLI类型来编程，并通过这种方式来提供伺服状态下的可校验代码，例如可以作为SQL Server2005的一个SQL存储过程。

　　现在，还是回到这个问题上来，什么是C++/CLI？它是进行.NET编程模式的最佳切入点。对于C++/CLI，有一个来自C++的迁移路径，它不仅包含C++的底层基础，而且也需要C++编程经验，对于这些，我感到非常满意。

　　学习C++/CLI的方法

　　在设计C++/CLI语言中涉及三个方面问题，这同样贯彻于所有的其他程序开发语言：一是语言级的语法向底层通用类型系统（简称CTS）的映射；二是向程序开发人员提供的CLI的底层细节结构的级别选择；三是超越CLI的直接支持，提供额外的功能性函数的选择。

　　第一条对于所有的CLI语言来说都大致相同，第二条和第三条对于不同的CLI语言来说是不同的，相互区别的。根据你需要解决什么样的问题，你将选择这种或那种语言，也有可能混合使用多种CLI语言。学习C++/CLI涉及到了解它在设计过程中的所有这些涉及方面。

　　从C++/CLI到CTS的映射？

　　使用C++/CLI编程时间了解底层的CTS非常重要。CTS包括以下三种常用类的类型：

　　1、多态引用类型，这正是对于所有继承类所要使用的。

　　2、非多态值类型，这用于实时高效的具体类型，例如数值类型。

　　3、抽象的接口类型，这用于定义一个操作集，也可以用于实现接口的引用或值类型集合。

　　这个设计方面的问题，即将CTS映射到语言内建的数据类型集合，通常同样贯穿于所有的CLI语言，虽然不同的CLI语言语法不同。所以，在C#中你可能这么写：

abstract class Shape { ... } // C#

　　来定义了一个Shape基类，从该类将导出几何对象，然而在C++/CLI你将这么写：

ref class Shape abstract { ... }; // C++/CLI

　　上述代码说明了底层的C++/CLI引用类型。这两种声明在内层代表的意思是一样的。相似地，在C#中你这么写：

struct Point2D { ... } // C#

　　来定义一个具体的Point2D 类，然而在C++/CLI中这么写：

value class Point2D { ... }; // C++/CLI

　　C++/CLI支持的类型集合代表了CTS与本地设备的综合，这决定了你的语法选择，例如：

class native {};
value class V {};
ref class R {};
interface class I {};

　　CTS也支持与本地列举类型稍微不同的列举类类型。当然，对于上述两者CTS是都支持的。例如：

enum native { fail, pass };
enum class CLIEnum : char { fail, pass};

　　相似地，CTS支持它本身的数组类型，并且它再一次将其与本地数组在行为上区分开来。同时，微软再次为这两种类型提供了支持。

int native[] = { 1,1,2,3,5,8 };
array^ managed = { 1,1,2,3,5,8 };

　　那种认为一种CLI语言比其他CLI语言在向底层的CTS映射中表现的更出色或更完美都是不确切的，相反，每种不同的CLI语言代表着对CTS底层对象模型的不同理解，在下一节你将更清楚地看到这一点。

　　CLI的细节

　　设计一个CLI语言时第二个必须要考虑的问题是将CLI的底层执行模式融入到语言的细节级别。这种语言用于解决什么问题？这种语言是否有必须的工具来解决这些问题？这种语言可能吸引什么样的程序开发人员？

　　例如，值类型存在于托管堆上，在很多情况下值类型可以看到它们自身的存在。

　　1、通过隐含的加箱操作，当一个值类型的实例被分配给一个对象或当一个虚拟的方法通过一个值类型来调用；

　　2、当这个值类型被当作应用引用类类型的成员时；

　　3、当这个值类型被当作CLI数组成员时；

　　需要指出的是，这种情况下开发人员是否被允许操作值类型的地址是CLI语言设计时必须应该予以考虑的问题。

　　存在的问题

　　在垃圾收集器扫描紧缩状态下，位于托管堆上的任何对象非常可能面对重新定位问题。指向对象的指针可以实时跟踪并修改。开发人员不能自己手动跟踪，所以，如果你获许取得一个可能位于托管堆上的值类型的地址时，除了本地指针外，还需要有一个跟踪形态的指针。

　　销售商考虑的是什么？那就是需要简单和安全，在语言中直接提供跟踪一个对象或集合的指针使语言复杂化，没有这种支持，将减少复杂程度，可资利用的、潜在的程序开发人群可能会增加，此外，准许程序开发人员操作生命短暂的值类型，增加了错误产生的可能性，程序开发人员可能有意无意地对内存进行错误操作，不支持跟踪指针，一个潜在的更安全地实时环境产生了。

　　另一方面，效率和灵活性也是必须考虑的一个问题，每一次向同一个对象分配值类型时，一个全新的数值加箱操作发生了，准许存取加箱值类型允许在内存中进行更新，这可能在性能上产生了一个非常巨大的进步。没有跟踪形态的指针，你无法用指针算法重新声明一个CLI数组，这意味着CLI数组不能使用标准模板库进行重新声明，也不能使用一般的算法。准许操作加箱数值使设计具有更大地灵活性。

　　微软在C++/CLI中选择地址集合模式来处理托管堆上的值类型。

int ival = 1024;
int^ boxedi = ival;
array^ ia = gcnew array{1,1,2,3,5,8};
interior_ptr begin = &ia[0];

value struct smallInt { int m_ival; ... } si;
pin_ptr ppi = &si.m_ival;

　　典型地C++/CLI开发人员是一个复杂的系统程序员，承担着提供下层内部构造和有组织的应用程序的任务，而这些恰恰是未来商业发展的基础。C++/CLI开发人员必须兼顾可测量性和可执行性，所以必须在系统的高度级上来看待CLI下层结构。CLI细节水平反映了开发人员的脸色。

　　复杂性本身并不代表对质量的否定，人类比单细胞细菌复杂的多，这当然不是一件坏事，然而，当表达一个简单的概念变的复杂化后，这常常被认为是一件坏事。在C++/CLI中，CLI开发团队已经试着提供一种精巧的方法来表达方式一个复杂的事情。

　　额外增加的功能

　　第三个设计方面是特定功能性的语言层，它远远超过CLI所提供的直接支持，虽然这可能需要在语言层支持和CLI底层执行模式间建立一个映射。但在某些情况下，这恰恰是不可能的，因为语言无法调节CLI的行为。这种情况的例子就是在基类的构造及析构函数中定义虚函数。根据ISO-C++在这种情况下的语言学，需要用每一个基类的构造和虚构函数重新设置虚拟表，而这是不可能的，因为虚拟表句柄是实时管理的，而不是某一个语言来管理。

　　所以，这个设计方面是在完美性和可行性之间的妥协产物，C++/CLI提供的额外功能主要表现在三个方面：

　　1、获取资源的一种形式是对于引用类型的初始化，此外，提供一种自动化工具，用于占用较少资源、所谓的可确定性自动消亡的垃圾收集类型对象。

　　2、一种深度拷贝形式的语法与C++拷贝构造函数和拷贝分配操作符相一致，但其并不适用与值类型。

　　3、除了最初的一般性CLI机制外，还有对于CTS类型的C++模板直接支持。这些是我第一篇文章中讨论的主题。此外，还提供了针对CLI类型的可校验STL版本。

　　让我们来看一个简单的例子，一个确定性消亡问题。在垃圾搜集器重新声明一块与对象相关联的内存之前，一个相关的消亡方法，如果存在的话，将被调用。你可以认为这种方法是超级析构函数，因为它与对象的程序生命期无关。这就叫做终结。终结函数是否调用以及什么时间调用都没有明确规定，这就是垃圾收集器的非确定性终结。

　　在动态内存管理的情况下，非确定性终结工作非常好，当可用内存变的越来越少时，垃圾收集器介入并开始着手解决问题。然而，非决定性终结也有工作不好的时候，当一个对象维护一个重要资源，例如一个数据库连接、锁定某些类别、或者可能是本地的堆内存。在这种情况下，只要是不需要，应立即释放资源。目前CLI所支持的解决问题的方法是，对于一个类通过执行IDisposable接口提供的Dispose方法释放资源。这里的问题是执行Dispose方法需要一个清晰的声明，所以它也就不可能存在调用。

　　最基本的C++中的设计模式是上述的通过初始化来获取资源，这意味着类使用构造函数来获取资源，相反，类使用析构函数来释放资源。这些行为由类对象在生存期内自动管理。

　　下面是引用类释放资源时所做的顺序动作：

　　1、首先使用析构函数来封装所有与释放类有关的资源时所必须的代码；

　　2、析构函数自动调用后，结束类对象的生命期。

　　对于引用类型来说，CLI没有类析构函数的概念，所以析构函数不得不映射为在底层执行的其它代码。此时，在内部，编译器执行以下操作：

　　1、类让其基类列表继承自IDisposable接口；

　　2、析构函数转换成IDisposable的Dispose方法。

　　以上实现了目标的一半，一种实现析构造函数自动调用的方法仍然需要，对于引用类型，一种特殊的基于栈的符号得到支持，也就是说，一个对象的生命期与它的声明范围有关。在内部，编译器将符号转换为在托管堆上分配引用对象。随着作用域的终结，编译器插入一个Dispose方法-用户定义的析构函数。与对象有关的内存的收回在垃圾收集器的控制下得到执行。

　　C++/CLI并不是将C++拓展到一个托管的世界，更确切的说，它代表一个完全综合的范例，某种程度上就象当初将泛编程模式和多重继承综合进该语言一样。我认为C++/CLI开发小组做了一项非常卓有成效的工作。

　　小结

　　C++/CLI代表托管和本地编程的结合。在反复过程中，这种综合已经通过源级相对独立但又相互平等地组件和二进制元素得到了完成，包括混合模式（本地和CTS类型的源级混合，还有一个本地及CLI对象文件的二进制混合），纯模式（本地和CTS类型的源代码级混合，所有的都被编译为CLI对象文件），本地分类（可以通过一个特定的打包类来保持CTS类型），和CTS分类（可以保持本地类型为指针）。

　　当然，C++/CLI开发人员也可以单独使用CLI类型来编程，并通过这种方式来提供伺服状态下的可校验代码，例如可以作为SQL Server2005的一个SQL存储过程。

　　现在，还是回到这个问题上来，什么是C++/CLI？它是进行.NET编程模式的最佳切入点。对于C++/CLI，有一个来自C++的迁移路径，它不仅包含C++的底层基础，而且也需要C++编程经验，对于这些，我感到非常满意。

@王一伟 2007-02-10 19:13 发表评论

C++博客-酱坛子

最近做地图遇到Z-buffer精度问题

实时3D绘图的阴影效果

内存文件映射应用举例『转』

#pragma once与#ifndef的区别

在入口函数内加如该段代码 能对内存泄露进行输出

哈希表（摘）

CL.exe的全部命令开关(摘)

被误解的C++——优化variant实现(摘抄)

被误解的C++——优化variant实现

函数指针当参数传入的写法

Assert 宏

虚拟继承

可变参数函数设计

MFC RTTI的三个宏

线程安全

_stdcall(WINAPI) 与 _cdecl的区别

EXPORTER LAB

EXPORTER LAB

Table of Contents

PHASE 0: STARTING OUT

PHASE 1 : GEOMETRY

PHASE 2 : TEXTURES AND LIGHTING

PHASE 3: ANIMATION AND MODIFIERS

PHASE 4: CUSTOM DATA

OTHER STRATEGIES, FUTURE DIRECTIONS

Legend

PHASE 0: STARTING OUT

Plug-in Requirements

Try it

PHASE 1 : GEOMETRY

Try it

Meshes

Try it

Patches

Try it

PHASE 2 : TEXTURES AND LIGHTING

Textures

Try it

Texture Vertices in Meshes

Texture Vertices in Patches

Try it

Lighting

Try it

PHASE 3: ANIMATION AND MODIFIERS

Try it

Accessing Modifiers

Try it

Animated Parameters

Try it

Bones and IK

PHASE 4: CUSTOM DATA

Per-node custom data -- AppData

Per-node custom data – UserProps

Per-Vertex custom data

Per-Face custom data

Texture-channel custom data

Try it

OTHER STRATEGIES, FUTURE DIRECTIONS

函数用const修饰算不算重载

MFC类中获得其它类指针

GetProcAddress

常用字符串件的类型转换

The PIMPL idiom

SQL参考

宽度优先搜索

正则表达式

正则表达式之道

目 录

什么是正则表达式

正则表达式基础

简单的例子

中级的例子（神奇的咒语）

例1

例2

例3

困难的例子（不可思议的象形文字）

不同工具中的正则表达式

sed

awk

在入口函数内加如该段代码能对内存泄露进行输出

目录

女人们的友谊与男人们的友谊（轻松下）