我们的这款游戏从开发到上线至今已有大概4年了，昨天发现代码中有new出来的对象没有delete，程序退出后VS输出栏中居然没有提示，难道程序中没有内存泄漏检察？进一步的求证确定了我的担忧（我是半路进的项目组）。在代码中加上_CrtSetDbgFlag(_CrtSetDbgFlag(_CRTDBG_REPORT_FLAG) | _CRTDBG_LEAK_CHECK_DF)后，VS的输出栏赫然显示了大量的内存泄漏。在动手解决内存泄漏之前，先复习一下有关new操作符重载的相关知识：

new 操作符按其可见性可分为全局的与局部的(类成员)，我们可以对他们进行重载，下面是VS 2010中new.cpp中new操作符的声明

调用new时，传入的参数比new声明时的参数少了一个，即第一个参数，该参数是new的对象的大小，由编译器填写，禁止程序员自己插手。

对一个类重载new和delete

当我们new一个自定义类时，如果该类重载了new操作符，则优先使用该类内部定义的new，如果这时非要调用全局的new操作符怎么办呢？可以在new前面加两个冒号:

下面回到解决内存泄漏的步骤上：

1 在程序必定会执行的路径上加上：

不一定非得是程序的最开始处

2 使用上面给出的第2个new操作符，当程序退出时，它会在VS输出栏中注明是哪行代码引起的内存泄漏。即所有的new 都改为

完了。。。。。这样就可以了。

但是，我们程序已有的代码都写的是new，而不是new ( _NORMAL_BLOCK, __FILE__, __LINE__ )。

MFC中的解决方法：

这样好像是可以解决问题，但是我们游戏中用了Gamebryo游戏引擎，这个引擎中很多类内部重载了new操作符，并且还有如下的宏定义：

并且引擎自带的对象都是通过NiNew来创建的，如 NiNew NiAlphaProperty();

如果我们把new 宏定义成了new ( _NORMAL_BLOCK, __FILE__, __LINE__ )，那么碰到NiNew NiAlphaProperty()后，代码就被展开成为

new ( _NORMAL_BLOCK, __FILE__, __LINE__ )  ( NI_MEMHINT_NONE, __FILE__, __LINE__ , __FUNCTION__ ) NiAlphaProperty(); 当编译器尝试着用此代码与NiAlphaProperty类内部定义的new操作符去匹配时就抓瞎了，只能报错。

目前就只能自己再定义一个宏:

将代码中所有的new替换成New。

另一种内存泄漏检测方法就是借用第3方的库:
Visual Leak Detector 是一个不错的泄漏检测库，下载地址：
http://vld.codeplex.com/releases/view/82311
只需要在自己的程序的main函数所在的文件中#include <vld.h>就可以了，使用起来很方便。

(注: _CrtSetBreakAlloc()对大型的C++工程不太实用 )

1、关联


双向关联：
C1-C2：指双方都知道对方的存在，都可以调用对方的公共属性和方法。

在GOF的设计模式书上是这样描述的：虽然在分析阶段这种关系是适用的，但我们觉得它对于描述设计模式内的类关系来说显得太抽象了，因为在设计阶段关联关系必须被映射为对象引用或指针。对象引用本身就是有向的，更适合表达我们所讨论的那种关系。所以这种关系在设计的时候比较少用到，关联一般都是有向的。

使用ROSE 生成的代码是这样的：

class C1 
...{
public:
    C2* theC2;

};

class C2 
...{
public:
    C1* theC1;

};

双向关联在代码的表现为双方都拥有对方的一个指针，当然也可以是引用或者是值。





单向关联:
C3->C4：表示相识关系，指C3知道C4，C3可以调用C4的公共属性和方法。没有生命期的依赖。一般是表示为一种引用。

生成代码如下：

class C3 
...{
public:
    C4* theC4;

};

class C4 
...{

};

单向关联的代码就表现为C3有C4的指针，而C4对C3一无所知。

自身关联（反身关联）：
自己引用自己，带着一个自己的引用。

代码如下：

class C14 
...{
public:
    C14* theC14;

};

就是在自己的内部有着一个自身的引用。

2、聚合/组合

当类之间有整体-部分关系的时候，我们就可以使用组合或者聚合。



聚合：表示C9聚合C10，但是C10可以离开C9而独立存在（独立存在的意思是在某个应用的问题域中这个类的存在有意义。这句话怎么解，请看下面组合里的解释）。

代码如下：

class C9 
...{
public:
    C10 theC10;

};

class C10 
...{

};

组合（也有人称为包容）：一般是实心菱形加实线箭头表示，如上图所示，表示的是C8被C7包容，而且C8不能离开C7而独立存在。但这是视问题域而定的，例如在关心汽车的领域里，轮胎是一定要组合在汽车类中的，因为它离开了汽车就没有意义了。但是在卖轮胎的店铺业务里，就算轮胎离开了汽车，它也是有意义的，这就可以用聚合了。在《敏捷开发》中还说到，A组合B，则A需要知道B的生存周期，即可能A负责生成或者释放B，或者A通过某种途径知道B的生成和释放。

他们的代码如下：

class C7 
...{
public:
    C8 theC8;

};

class C8 
...{
};

可以看到，代码和聚合是一样的。具体如何区别，可能就只能用语义来区分了。

3、依赖



依赖:
指C5可能要用到C6的一些方法，也可以这样说，要完成C5里的所有功能，一定要有C6的方法协助才行。C5依赖于C6的定义，一般是在C5类的头文件中包含了C6的头文件。ROSE对依赖关系不产生属性。

注意，要避免双向依赖。一般来说，不应该存在双向依赖。

ROSE生成的代码如下：

// C5.h
#include "C6.h"

class C5 
...{

};

// C6.h
#include "C5.h"

class C6
...{

};

虽然ROSE不生成属性，但在形式上一般是A中的某个方法把B的对象作为参数使用(假设A依赖于B)。如下：

#include "B.h"
class A
...{
          void Func(B &b);
}

那依赖和聚合\组合、关联等有什么不同呢？

关联是类之间的一种关系，例如老师教学生，老公和老婆，水壶装水等就是一种关系。这种关系是非常明显的，在问题领域中通过分析直接就能得出。

依赖是一种弱关联，只要一个类用到另一个类，但是和另一个类的关系不是太明显的时候（可以说是“uses”了那个类），就可以把这种关系看成是依赖，依赖也可说是一种偶然的关系，而不是必然的关系，就是“我在某个方法中偶然用到了它，但在现实中我和它并没多大关系”。例如我和锤子，我和锤子本来是没关系的，但在有一次要钉钉子的时候，我用到了它，这就是一种依赖，依赖锤子完成钉钉子这件事情。

组合是一种整体-部分的关系，在问题域中这种关系很明显，直接分析就可以得出的。例如轮胎是车的一部分，树叶是树的一部分，手脚是身体的一部分这种的关系，非常明显的整体-部分关系。

上述的几种关系（关联、聚合/组合、依赖）在代码中可能以指针、引用、值等的方式在另一个类中出现，不拘于形式，但在逻辑上他们就有以上的区别。

这里还要说明一下，所谓的这些关系只是在某个问题域才有效，离开了这个问题域，可能这些关系就不成立了，例如可能在某个问题域中，我是一个木匠，需要拿着锤子去干活，可能整个问题的描述就是我拿着锤子怎么钉桌子，钉椅子，钉柜子；既然整个问题就是描述这个，我和锤子就不仅是偶然的依赖关系了，我和锤子的关系变得非常的紧密，可能就上升为组合关系（让我突然想起武侠小说的剑不离身，剑亡人亡...）。这个例子可能有点荒谬，但也是为了说明一个道理，就是关系和类一样，它们都是在一个问题领域中才成立的，离开了这个问题域，他们可能就不复存在了。


4、泛化（继承）



泛化关系：如果两个类存在泛化的关系时就使用，例如父和子，动物和老虎，植物和花等。
ROSE生成的代码很简单，如下：

#include "C11.h"

class C12 : public C11
...{
};

5、这里顺便提一下模板



上面的图对应的代码如下：

template<int>
class C13 
...{
};

这里再说一下重复度，其实看完了上面的描述之后，我们应该清楚了各个关系间的关系以及具体对应到代码是怎么样的，所谓的重复度，也只不过是上面的扩展，例如A和B有着“1对多”的重复度，那在A中就有一个列表，保存着B对象的N个引用，就是这样而已。

好了，到这里，已经把上面的类图关系说完了，希望你能有所收获了，我也费了不少工夫啊（画图、生成代码、截图、写到BLOG上，唉，一头大汗）。不过如果能让你彻底理解UML类图的这些关系，也值得了。:)

class my_class { public :     my_class()     {         m_member = 1;     }       void method(int n)     {         m_member = n;     }       ~my_class()     {         m_member = 0;     }   private :     int m_member; };   int _tmain(int argc, _TCHAR* argv[]) {     my_class a_class;     a_class.method(10);       return 0; }

_TEXT SEGMENT _wmain      PROC       push ebp                                 ; 保存旧的ebp       mov   ebp, esp                            ; ebp保存当前栈的位置       push -1                                  ; 建立SEH(Structured Exception Handler)链                                                 ; -1表示表头,没有Prev       push __ehhandler$_wmain                  ; SEH异常处理程序的地址       mov   eax, DWORD PTR fs:0                 ; fs:0指向TEB的内容，头4个字节是当前SEH链的地址       push eax                                 ; 保存起来       sub   esp, d8H                            ; 分配d8H字节的空间       push ebx       push esi       push edi       lea   edi, DWORD PTR [ebp-e4H]            ; e4H = d8H + 4 * 3，跳过中间ebx, esi, edi       mov   ecx, 36H                            ; 36H*4H=d8H，也就是用36H个ccccccccH填满刚才分配的d8H字节空间       mov   eax, ccccccccH       rep stosd       mov   eax, DWORD PTR ___security_cookie         xor   eax, ebp                       push eax                                 ; ebp ^ __security_cookie压栈保存       lea   eax, DWORD PTR [ebp-0cH]            ; ebp-0cH是新的SEH链的结构地址（刚压入栈中的栈地址）       mov   DWORD PTR fs:0, eax                 ; 设置到TEB中作为当前Active的SEH链表末尾

Security cookie after XOR

Edi

Esi

Ebx

Local stack: d8H

Old fs:0

__ehhandler$_wmain

ffffffffH

Old ebp

lea   ecx, DWORD PTR [ebp-14H]    call ??0my_class@@QAE@XZ                 ; 调用my_class::my_class, ??my_class@@QAE@XZ是经过Name Mangling后的名字    mov   DWORD PTR [ebp-4], 0                ; 进入__try块，在Main中有一个隐式的__try/__except块

push 10                                  ; 参数入栈       lea   ecx, DWORD PTR [ebp-14H]            ; 遵循thiscall调用协定，ecx存放的是this指针       call ?method@my_class@@QAEXH@Z           ; 调用子程序my_class:method(10)

mov   DWORD PTR [ebp-e0H], 0             ; 用来放置返回值       mov   DWORD PTR [ebp-4], -1               ; 标记TRY的正常结束       lea   ecx, DWORD PTR [ebp-14H]            ; a_class的地址作为this存入ECX       call ??1my_class@@QAE@XZ                 ; my_class::~my_class       mov   eax, DWORD PTR [ebp-e0H]            ; 返回值按照约定放入eax中

push edx       mov   ecx, ebp       push eax       lea   edx, DWORD PTR $LN7@wmain       call @_RTC_CheckStackVars@8             ; 检查栈       pop   eax       pop   edx       mov   ecx, DWORD PTR [ebp-0cH]            ; 取出之前保存的旧的fs:0，并恢复       mov   DWORD PTR fs:0, ecx       pop   ecx       pop   edi       pop   esi       pop   ebx       add   esp, e4H                            ; 退掉分配的d8H + 建立SEH链所需的0cH字节       cmp   ebp, esp       call __RTC_CheckEsp                      ; 检查esp值，这个时候esp应该和ebp匹配，否则说明出现了栈不平衡的情况，这种情况下调用子程序报错       mov   esp, ebp                            ; 恢复ebp到esp       pop   ebp                                 ; 恢复原来的ebp值       ret   0 _wmain      ENDP

Text$x      SEGMENT __unwindfunclet$_wmain$0:                       ; 当SEH发生的时候会调用该函数，析购a_class       lea   ecx, DWORD PTR [ebp-14H]            ; ecx = [ebp – 14H]，也就是a_class的地址       jmp   ??1my_class@@QAE@XZ                 ; 调用my_class::~my_class __ehhandler$_wmain:       mov   edx, DWORD PTR [esp+8]             ; esp = 当前的fs:0, [esp + 8] = 之前的SEH结构，也就是main中建立的       lea   eax, DWORD PTR [edx+0cH]            ; edx + 0Ch = 当前的ebp，也就是main的ebp，此时不能直接使用ebp因为可能会从任意函数调过来，此时ebp是该函数的ebp，而不是main的ebp       mov   ecx, DWORD PTR [edx-e0H]            ; 之前存下去的__security_cookie ^ ebp       xor   ecx, eax                            ; 再次和ebp相异或       call @__security_check_cookie@4          ; 此时ecx应该等于__security_cookie，否则说明栈的内容被恶意改动（或者编程错误）       mov   eax, OFFSET __ehfuncinfo$_wmain       jmp   ___CxxFrameHandler3 text$x      ENDS

_TEXT SEGMENT ??0my_class@@QAE@XZ PROC       push ebp                                 ; 保存旧的ebp       mov   ebp, esp                            ; ebp保存当前栈的位置       sub   esp, ccH                            ; 给栈分配ccH个字节       push ebx                                 ; 保存常用寄存器       push esi       push edi       push ecx       lea   edi, DWORD PTR [ebp-ccH]            ; 从分配的位置开始       mov   ecx, 33H                            ; 写33H个ccccccccH       mov   eax, ccccccccH                      ; 也就是33H*4H=ccH，正好是分配的大小       rep stosd                                 ; 从而把整个栈上当前分配的空间用ccH填满       pop   ecx       mov   DWORD PTR [ebp-8], ecx             ; 按照约定，一般用ECX保存this指针                                                 ; 把this存入到ebp-8，并不是很必要，因为这是Debug版本                                                   ; 10   :     { ; 11   :         m_member = 1;         mov   eax, DWORD PTR [ebp-8]             ; eax中存放this       mov   DWORD PTR [eax], 1                  ; this的头四个byte是m_member的内容   ; 12   :     }         mov   eax, DWORD PTR [ebp-8]             ; 多余的一句话，可以优化掉       pop   edi       pop   esi       pop   ebx       mov   esp, ebp                            ; 恢复esp，因此就算是中间栈运算出错，最后也不会导致灾难性的结果，只要ebp还是正确的       pop   ebp       ret   0 ??0my_class@@QAE@XZ ENDP

_TEXT SEGMENT ?method@my_class@@QAEXH@Z PROC                  ; my_class::method   ; 15   :     {         push ebp       mov   ebp, esp       sub   esp, ccH       push ebx       push esi       push edi       push ecx       lea   edi, DWORD PTR [ebp-ccH]       mov   ecx, 33H       mov   eax, ccccccccH       rep stosd       pop   ecx       mov   DWORD PTR [ebp-8], ecx   ; 16   :         m_member = n;         mov   eax, DWORD PTR [ebp-8]             ; eax中存放this       mov   ecx, DWORD PTR [ebp+8]             ; ebp -> ebp                                                 ; ebp + 4 -> IP                                                 ; ebp + 8 -> n                                                 ; 把n存入ecx中       mov   DWORD PTR [eax], ecx                ; this头四个字节是m_member, 因此这句话就是m_member = n   ; 17   :     }         pop   edi       pop   esi       pop   ebx       mov   esp, ebp       pop   ebp       ret   4                                   ; 等价于                                                 ; ret 恢复EIP，返回调用地址                                                 ; add esp, 4 -> 把n从栈上Pop掉 ?method@my_class@@QAEXH@Z ENDP

_TEXT SEGMENT ??1my_class@@QAE@XZ PROC                        ; my_class::~my_class   ; 20   :     {         push ebp       mov   ebp, esp       sub   esp, 204                            push ebx       push esi       push edi       push ecx       lea   edi, DWORD PTR [ebp-204]       mov   ecx, 33H                            mov   eax, ccccccccH                      rep stosd       pop   ecx       mov   DWORD PTR _this$[ebp], ecx   ; 21   :         m_member = 0;         mov   eax, DWORD PTR [ebp-8]       mov   DWORD PTR [eax], 0   ; 22   :     }         pop   edi       pop   esi       pop   ebx       mov   esp, ebp       pop   ebp       ret   0 ??1my_class@@QAE@XZ ENDP                        ; my_class::~my_class

下面谈谈我所知道的一些公司信息，不全，仅仅是我所了解到的或者我所感兴趣的，实际远远不止这么多。

搜索方向
基于内容的图像或视频搜索是很多搜索公司研究的热点。要想进入这个领域，必须有很强的编程能力，很好的图像处理和模式识别的背景。要求高待遇自然就不错，目前这方面的代表公司有微软、google、yahoo和百度，个个鼎鼎大名。

医学图像方向
目前在医疗器械方向主要是几个大企业在竞争，来头都不小，其中包括Simens、GE、飞利浦和柯达，主要生产CT和MRI等医疗器材。由于医疗器械的主要功能是成像，必然涉及到对图像的处理，做图像处理的很有机会进入这些公司。它们在国内都设有研发中心，simens的在上海和深圳，GE和柯达都在上海，飞利浦的在沈阳。由于医疗市场是一个没有完全开发的市场，而一套医疗设备的价格是非常昂贵的，所以在这些地方的待遇都还可以，前景也看好。国内也有一些这样的企业比如深圳安科和迈瑞

计算机视觉和模式识别方向
我没去调研过有哪些公司在做，但肯定不少，比如指纹识别、人脸识别、虹膜识别。还有一个很大的方向是车牌识别，这个我倒是知道有一个公司高德威智能交通似乎做的很不错的样子。目前视频监控是一个热点问题，做跟踪和识别的可以在这个方向找到一席之地。
上海法视特位于上海张江高科技园区，在视觉和识别方面做的不错。北京的我也知道两个公司：大恒和凌云，都是以图像作为研发的主体。

视频方向
一般的高校或者研究所侧重在标准的制定和修改以及技术创新方面，而公司则侧重在编码解码的硬件实现方面。一般这些公司要求是熟悉或者精通MPEG、H.264或者AVS，选择了这个方向，只要做的还不错，基本就不愁饭碗。由于这不是我所感兴趣的方向，所以这方面的公司的信息我没有收集，但平常在各个bbs或者各种招聘网站经常看到。
我所知道的两个公司：诺基亚和pixelworks

其他
其实一般来说，只要涉及到成像或者图像的基本都要图像处理方面的人。比方说一个成像设备，在输出图像之前需要对原始图像进行增强或者去噪处理，存储时需要对图像进行压缩，成像之后需要对图像内容进行自动分析，这些内容都是图像处理的范畴。下面列举一些与图像有关或者招聘时明确说明需要图像处理方面人才的公司：
上海豪威集成电路有限公司（www.ovt.com.cn）
中芯微
摩托罗拉上海研究院
威盛（VIA）
松下
索尼
清华同方
三星
所有与图像（静止或者运动图像）有关的公司都是一种选择。比如数码相机、显微镜成像、超声成像、工业机器人控制、显示器、电视、遥感等等，都可以作为求职方向。

要求：
1、外语。如果进外企，外语的重要性不言而喻。一般外企的第一轮面试都是英语口语面试。
2、编程。这方面尤以C＋＋为重，很多公司的笔试都是考c＋＋知识。
3、专业水平。如果要找专业相关的工作，研究生期间的研究经历和发表的论文就显的比较重要。
4、知识面的宽度。我觉得在研究生期间，除了做好自己的研究方向之外，扩宽一下知识面也有很大的帮助，当然这个知识面指的是图像处理、计算机视觉和模式识别，知识面越宽，就业时的选择就会越多。

图像处理方向毕业的就业面非常广，而且待遇在应届生应该是中上等。其实还是一句话，能力决定一切。只要研究生三年没有白

　　实例一:
　　#include "stdafx.h"
　　#include <iostream.h>

　　class CB
　　{
　　public:
 　　　　void f(int)
 　　　　{
 　　　　　　 cout << "CB::f(int)" << endl;
　　　　 }

　　};

　　class CD : public CB
　　{
　　public:
　　　　 void f(int,int)
 　　　　{
  　　　　　　cout << "CD::f(int,int)" << endl;
 　　　　}

 　　　　void test()
 　　　　{
  　　　　　f(1);
 　　　　}
　　};

　int main(int argc, char* argv[])
　{
　　　 return 0;
　}
编译了一下
error C2660: 'f' : function does not take 1 parameters

结论：在类CD这个域中，没有f(int)这样的函数，基类中的void f(int)被隐藏

　　如果把派生CD中成员函数void f(int,int)的声明改成和基类中一样，即f(int)，基类中的void f(int)还是一样被覆盖，此时编译不会出错，在函数中test调用的是CD中的f(int)　

　　所以，在基类中的某些函数，如果没有virtral关键字，函数名是f(参数是什么我们不管)，那么如果在派生类CD中也声明了某个f成员函数，那么在类CD域中，基类中所有的那些f都被隐藏。
　　如果你比较心急，想知道什么是隐藏，看文章最后的简单说明，不过我建议你还是一步一步看下去。

　　我们刚才说的是没有virtual的情况，如果有virtual的情况呢？？
　　实例二：

#include "stdafx.h"
#include <iostream.h>

class CB
{
public:
 　　virtual void f(int)
 　　{
  　　　　cout << "CB::f(int)" << endl;
 　　}

};

class CD : public CB
{
public:
　　 void f(int)
 　　{
  　　　　cout << "CD::f(int)" << endl;
　　 }

};

int main(int argc, char* argv[])
{
 　return 0;
}

　　这么写当然是没问题了，在这里我不多费口舌了，这是很简单的，多态，虚函数，然后什么指向基类的指针指向派生类对象阿，通过引用调用虚函数阿什么的，属性多的很咯，什么？？你不明白？？随便找本C++的书，对会讲多态和虚函数机制的哦！！
　　这种情况我们叫覆盖(override)！覆盖指的是派生类的虚拟函数覆盖了基类的同名且参数相同的函数！
　　在这里，我要强调的是，这种覆盖，要满足两个条件
　(a)有virtual关键字，在基类中函数声明的时候加上就可以了
　(b)基类CB中的函数和派生类CD中的函数要一模一样，什么叫一模一样，函数名，参数，返回类型三个条件。
　　有人可能会对(b)中的说法质疑，说返回类型也要一样？？
　　是，覆盖的话必须一样，我试了试，如果在基类中,把f的声明改成virtual int f(int)，编译出错了
　　error C2555: 'CD::f' : overriding virtual function differs from 'CB::f' only by return type or calling convention
　　所以，覆盖的话，必须要满足上述的(a)(b)条件

　　那么如果基类CB中的函数f有关键字virtual　，但是参数和派生类CD中的函数f参数不一样呢，
实例三:
  #include "stdafx.h"
#include <iostream.h>

class CB
{
　public:
 　　 virtual  void f(int)
　　 {
 　　　　 cout << "CB::f(int)" << endl;
　　 }

}
;

class CD : public CB
{
public:
 　　 void f(int，int)
 　　{
 　　　 cout << "CD::f(int，int)" << endl;
 　　}

 　　void test()
 　　{
 　　　　 f(1);
 　　}
}
;

int main(int argc, char* argv[])
{
 return 0;
}

编译出错了，
 error C2660: 'f' : function does not take 1 parameters
　　咦？？好面熟的错？？对，和实例一中的情况一样哦，结论也是基类中的函数被隐藏了。

　　通过上面三个例子，得出一个简单的结论
如果基类中的函数和派生类中的两个名字一样的函数f
满足下面的两个条件
(a)在基类中函数声明的时候有virtual关键字
(b)基类CB中的函数和派生类CD中的函数一模一样，函数名，参数，返回类型都一样。
那么这就是叫做覆盖(override)，这也就是虚函数，多态的性质

那么其他的情况呢？？只要名字一样，不满足上面覆盖的条件，就是隐藏了。

下面我要讲最关键的地方了，好多人认为，基类CB中的f(int)会继承下来和CD中的f(int,int)在派生类CD中构成重载，就像实例一中想像的那样。
　　对吗？我们先看重载的定义
　　重载(overload):
　　必须在一个域中,函数名称相同但是函数参数不同,重载的作用就是同一个函数有不同的行为,因此不是在一个域中的函数是无法构成重载的,这个是重载的重要特征
　　必须在一个域中，而继承明显是在两个类中了哦，所以上面的想法是不成立的，我们测试的结构也是这样，派生类中的f(int,int)把基类中的f(int)隐藏了
　　所以，相同的函数名的函数，在基类和派生类中的关系只能是覆盖或者隐藏。

　　在文章中，我把重载和覆盖的定义都给了出来了，但是一直没有给隐藏的定义，在最后，我把他给出来，这段话是网上google来的，比较长，你可以简单的理解成，在派生类域中，看不到基类中的那个同名函数了，或者说，是并没有继承下来给你用，呵呵，如实例一　那样。
　　

隐藏(hide):
指的是派生类的成员函数隐藏了基类函数的成员函数.隐藏一词可以这么理解:在调用一个类的成员函数的时候,编译器会沿着类的继承链逐级的向上查找函数的定义,如果找到了那么就停止查找了,所以如果一个派生类和一个基类都有同一个同名(暂且不论参数是否相同)的函数,而编译器最终选择了在派生类中的函数,那么我们就说这个派生类的成员函数"隐藏"了基类的成员函数,也就是说它阻止了编译器继续向上查找函数的定义.

break NUM 在指定的行上设置断点  break 1

bt 显示函数的调用顺序

clear 删除断点 clear test.c:10 

display expr 每次程序停止后显示表达式的值

printf expr显示表达式的值。与display expr是有区别的

file filename装载文件进行调试

info break;显示断点清单

info files 显示被调试文件的信息

info func显示所有函数名称

info local显示当前函数中的局部变量信息

info var 显示所有的全局和静态变量名称。

info prog 显示被调试程序的执行状态。

kill 终止正在被调试的程序

list 显示源代码

next 单步调试

where 显示程序出错的地方。

下载源代码

本文的目的是设计一个完成URL编码的C++类。在我曾经的项目中，我需要从VC++ 6.0应用程序中POST数据，而这些数据需要进行URL编码。我在MSDN中查找能根据提供的字符串生成URL编码的相关类或API，但我没有找到，因此我必须设计一个自己的URLEncode C++类。

URLEncoder.exe是一个使用URLEncode类的MFC对话框程序。

如何处理

一些特殊字符在Internet上传送是件棘手的事情, 经URL编码特殊处理，可以使所有字符安全地从Internet传送。

例如，回车的ASCII值是13，在发送FORM数据时候这就认为是一行数据的结束。

通常，所有应用程序采用HTTP或HTTPS协议在客户端和服务器端传送数据。服务器端从客户端接收数据有两种基本方法：

1、数据可以从HTTP头传送（COOKIES或作为FORM数据发送）
2、可以包含在URL中的查询部分

当数据包含在URL，它必须遵循URL语法进行编码。在WEB服务器端，数据自动解码。考虑一下下面的URL，哪个数据是作为查询参数。

例如：http://WebSite/ResourceName?Data=Data

WebSite是URL名称
ResourceName可以是ASP或Servlet名称
Data是需要发送的数据。如果MIME类型是Content-Type: application/x-www-form-urlencoded，则要求进行编码。

RFC 1738

RFC 1738指明了统一资源定位(URLs)中的字符应该是US-ASCII字符集的子集。这是受HTML的限制，另一方面，允许在文档中使用所有ISO- 8859-1(ISO-Latin)字符集。这将意味着在HTML FORM里POST的数据（或作为查询字串的一部分），所有HTML编码必须被编码。

ISO-8859-1 (ISO-Latin)字符集

在下表中，包含了完整的ISO-8859-1 (ISO-Latin)字符集，表格提供了每个字符范围（10进制），描述，实际值，十六进制值，HTML结果。某个范围中的字符是否安全。

所有不安全的ASCII字符都需要编码，例如，范围(32-47, 58-64, 91-96, 123-126)。
下表描述了这些字符为什么不安全。

如何实现

字符的URL编码是将字符转换到8位16进制并在前面加上''%''前缀。例如，US-ASCII字符集中空格是10进制
的32或16进制的20，因此，URL编码是%20。

URLEncode: URLEncode是一个C++类，来实现字符串的URL编码。CURLEncode类包含如下函数：
isUnsafeString
decToHex
convert
URLEncode

URLEncode()函数完成编码过程，URLEncode检查每个字符，看是否安全。如果不安全将用%16进制值进行转换并添加
到原始字符串中。

代码片断 :

class CURLEncode
{
private:
  static CString csUnsafeString;
  CString (char num, int radix);
  bool isUnsafe(char compareChar);
  CString convert(char val);

public:
  CURLEncode() { };
  virtual ~CURLEncode() { };
  CString (CString vData);
};

bool CURLEncode::isUnsafe(char compareChar)
{
  bool bcharfound = false;
  char tmpsafeChar;
  int m_strLen = 0;

  m_strLen = csUnsafeString.GetLength();
  for(int ichar_pos = 0; ichar_pos < m_strLen ;ichar_pos++)
  {
    tmpsafeChar = csUnsafeString.GetAt(ichar_pos);
    if(tmpsafeChar == compareChar)
    {
      bcharfound = true;
      break;
    }
  }
  int char_ascii_value = 0;
  //char_ascii_value = __toascii(compareChar);
  char_ascii_value = (int) compareChar;

  if(bcharfound == false &&  char_ascii_value > 32 &&
                             char_ascii_value < 123)
  {
    return false;
  }
  // found no unsafe chars, return false
  else
  {
    return true;
  }

  return true;
}

CString CURLEncode::decToHex(char num, int radix)
{
  int temp=0;
  CString csTmp;
  int num_char;

num_char = (int) num;
  if (num_char < 0)
    num_char = 256 + num_char;

  while (num_char >= radix)
    {
    temp = num_char % radix;
    num_char = (int)floor(num_char / radix);
    csTmp = hexVals[temp];
    }

  csTmp += hexVals[num_char];

  if(csTmp.GetLength() < 2)
  {
    csTmp += ''0'';
  }

  CString strdecToHex(csTmp);
  // Reverse the String
  strdecToHex.MakeReverse();

  return strdecToHex;
}

CString CURLEncode::convert(char val)
{
  CString csRet;
  csRet += "%";
  csRet += decToHex(val, 16);
  return  csRet;
}

原文出处：http://msdn.microsoft.com/msdnmag/issues/1000/Winsock/

通常要开发网络应用程序并不是一件轻松的事情，不过，实际上只要掌握几个关键的原则也就可以了——创建和连接一个套接字，尝试进行连接，然后收发数据。真正难的是要写出一个可以接纳少则一个，多则数千个连接的网络应用程序。本文将讨论如何通过Winsock2在Windows NT 和 Windows 2000上开发高扩展能力的Winsock应用程序。文章主要的焦点在客户机/服务器模型的服务器这一方，当然，其中的许多要点对模型的双方都适用。

API与响应规模

通过Win32的重叠I/O机制，应用程序可以提请一项I/O操作，重叠的操作请求在后台完成，而同一时间提请操作的线程去做其他的事情。等重叠操作完成后线程收到有关的通知。这种机制对那些耗时的操作而言特别有用。不过，像Windows 3.1上的WSAAsyncSelect()及Unix下的select()那样的函数虽然易于使用，但是它们不能满足响应规模的需要。而完成端口机制是针对操作系统内部进行了优化，在Windows NT 和 Windows 2000上，使用了完成端口的重叠I/O机制才能够真正扩大系统的响应规模。

完成端口

一个完成端口其实就是一个通知队列，由操作系统把已经完成的重叠I/O请求的通知放入其中。当某项I/O操作一旦完成，某个可以对该操作结果进行处理的工作者线程就会收到一则通知。而套接字在被创建后，可以在任何时候与某个完成端口进行关联。

通常情况下，我们会在应用程序中创建一定数量的工作者线程来处理这些通知。线程数量取决于应用程序的特定需要。理想的情况是，线程数量等于处理器的数量，不过这也要求任何线程都不应该执行诸如同步读写、等待事件通知等阻塞型的操作，以免线程阻塞。每个线程都将分到一定的CPU时间，在此期间该线程可以运行，然后另一个线程将分到一个时间片并开始执行。如果某个线程执行了阻塞型的操作，操作系统将剥夺其未使用的剩余时间片并让其它线程开始执行。也就是说，前一个线程没有充分使用其时间片，当发生这样的情况时，应用程序应该准备其它线程来充分利用这些时间片。

完成端口的使用分为两步。首先创建完成端口，如以下代码所示：

HANDLE    hIocp;
hIocp = CreateIoCompletionPort(
    INVALID_HANDLE_VALUE,
    NULL,
    (ULONG_PTR)0,
    0);
if (hIocp == NULL) {
    // Error
}

SOCKET    s;

s = socket(AF_INET, SOCK_STREAM, 0);
if (s == INVALID_SOCKET) {
    // Error
if (CreateIoCompletionPort((HANDLE)s,
                           hIocp,
                           (ULONG_PTR)0,
                           0) == NULL)
{
// Error
}
...
}

在创建了完成端口、将一个或多个套接字与之相关联之后，我们就要创建若干个线程来处理完成通知。这些线程不断循环调用GetQueuedCompletionStatus ()函数并返回完成通知。

下面，我们先来看看应用程序如何跟踪这些重叠操作。当应用程序调用一个重叠操作函数时，要把指向一个overlapped结构的指针包括在其参数中。当操作完成后，我们可以通过GetQueuedCompletionStatus()函数中拿回这个指针。不过，单是根据这个指针所指向的overlapped 结构，应用程序并不能分辨究竟完成的是哪个操作。要实现对操作的跟踪，你可以自己定义一个OVERLAPPED结构，在其中加入所需的跟踪信息。

无论何时调用重叠操作函数时，总是会通过其lpOverlapped参数传递一个OVERLAPPEDPLUS结构(例如WSASend、 WSARecv等函数)。这就允许你为每一个重叠调用操作设置某些操作状态信息，当操作结束后，你可以通过 GetQueuedCompletionStatus()函数获得你自定义结构的指针。注意OVERLAPPED字段不要求一定是这个扩展后的结构的第一个字段。当得到了指向OVERLAPPED结构的指针以后，可以用CONTAINING_RECORD宏取出其中指向扩展结构的指针。

OVERLAPPED 结构的定义如下：

typedef struct _OVERLAPPEDPLUS {
    OVERLAPPED        ol;
    SOCKET            s, sclient;
    int               OpCode;
    WSABUF            wbuf;
    DWORD             dwBytes, dwFlags;
    // 其它有用的信息
} OVERLAPPEDPLUS;

#define OP_READ     0
#define OP_WRITE    1
#define OP_ACCEPT   2

DWORD WINAPI WorkerThread(LPVOID lpParam)
{    
    ULONG_PTR       *PerHandleKey;
    OVERLAPPED      *Overlap;
    OVERLAPPEDPLUS  *OverlapPlus,
                    *newolp;
    DWORD           dwBytesXfered;

    while (1)
    {
        ret = GetQueuedCompletionStatus(
            hIocp,
            &dwBytesXfered,
            (PULONG_PTR)&PerHandleKey,
            &Overlap,
            INFINITE);
        if (ret == 0)
        {
            // Operation failed
            continue;
        }
        OverlapPlus = CONTAINING_RECORD(Overlap, OVERLAPPEDPLUS, ol);
    
    switch (OverlapPlus->OpCode)
    {
    case OP_ACCEPT:
        // Client socket is contained in OverlapPlus.sclient
        // Add client to completion port
            CreateIoCompletionPort(
                (HANDLE)OverlapPlus->sclient,
                hIocp,
                (ULONG_PTR)0,
                0);

        //  Need a new OVERLAPPEDPLUS structure
        //  for the newly accepted socket. Perhaps
        //  keep a look aside list of free structures.
        newolp = AllocateOverlappedPlus();
        if (!newolp)
        {
            // Error
        }
        newolp->s = OverlapPlus->sclient;
        newolp->OpCode = OP_READ;

        // This function prepares the data to be sent
        PrepareSendBuffer(&newolp->wbuf);
  
        ret = WSASend(
                newolp->s,
                &newolp->wbuf,
                1,
                &newolp->dwBytes,
                0,
                &newolp.ol,
                NULL);
        
        if (ret == SOCKET_ERROR)
        {
            if (WSAGetLastError() != WSA_IO_PENDING)
            {
            // Error
            }
        }

        // Put structure in look aside list for later use
        FreeOverlappedPlus(OverlapPlus);

        // Signal accept thread to issue another AcceptEx
        SetEvent(hAcceptThread);
        break;

    case OP_READ:
        // Process the data read    
        // ...

        // Repost the read if necessary, reusing the same
        // receive buffer as before
        memset(&OverlapPlus->ol, 0, sizeof(OVERLAPPED));
        ret = WSARecv(
              OverlapPlus->s,
              &OverlapPlus->wbuf,
              1,
              &OverlapPlus->dwBytes,
              &OverlapPlus->dwFlags,
              &OverlapPlus->ol,
              NULL);

        if (ret == SOCKET_ERROR)
        {
            if (WSAGetLastError() != WSA_IO_PENDING)
            {
                // Error
            }
        }
        break;

    case OP_WRITE:
        // Process the data sent, etc.
        break;
    } // switch
    } // while
}  // WorkerThread

要记住，如果重叠操作调用失败时(也就是说，返回值是SOCKET_ERROR，并且错误原因不是WSA_IO_PENDING)，那么完成端口将不会收到任何完成通知。如果重叠操作调用成功，或者发生原因是WSA_IO_PENDING的错误时，完成端口将总是能够收到完成通知。

Windows NT和Windows 2000的套接字架构

对于开发大响应规模的Winsock应用程序而言，对Windows NT和Windows 2000的套接字架构有基本的了解是很有帮助的。下图是Windows 2000中的Winsock架构：

与其它类型操作系统不同，Windows NT和Windows 2000的传输协议没有一种风格像套接字那样的、可以和应用程序直接交谈的界面，而是采用了一种更为底层的API，叫做传输驱动程序界面(Transport Driver Interface,TDI)。Winsock的核心模式驱动程序负责连接和缓冲区管理，以便向应用程序提供套接字仿真(在AFD.SYS文件中实现)，同时负责与底层传输驱动程序对话。

谁来负责管理缓冲区？

正如上面所说的，应用程序通过Winsock来和传输协议驱动程序交谈，而AFD.SYS负责为应用程序进行缓冲区管理。也就是说，当应用程序调用 send()或WSASend()函数来发送数据时，AFD.SYS将把数据拷贝进它自己的内部缓冲区(取决于SO_SNDBUF设定值)，然后send ()或WSASend()函数立即返回。也可以这么说，AFD.SYS在后台负责把数据发送出去。不过，如果应用程序要求发出的数据超过了 SO_SNDBUF设定的缓冲区大小，那么WSASend()函数会阻塞，直至所有数据发送完毕。

从远程客户端接收数据的情况也类似。只要不用从应用程序那里接收大量的数据，而且没有超出SO_RCVBUF设定的值，AFD.SYS将把数据先拷贝到其内部缓冲区中。当应用程序调用recv()或WSARecv()函数时，数据将从内部缓冲拷贝到应用程序提供的缓冲区。

多数情况下，这样的架构运行良好，特别在是应用程序采用传统的套接字下非重叠的send()和receive()模式编写的时候。不过程序员要小心的是，尽管可以通过setsockopt()这个API来把SO_SNDBUF和SO_RCVBUF选项值设成0(关闭内部缓冲区)，但是程序员必须十分清楚把 AFD.SYS的内部缓冲区关掉会造成什么后果，避免收发数据时有关的缓冲区拷贝可能引起的系统崩溃。

举例来说，一个应用程序通过设定SO_SNDBUF为0把缓冲区关闭，然后发出一个阻塞send()调用。在这样的情况下，系统内核会把应用程序的缓冲区锁定，直到接收方确认收到了整个缓冲区后send()调用才返回。似乎这是一种判定你的数据是否已经为对方全部收到的简洁的方法，实际上却并非如此。想想看，即使远端TCP 通知数据已经收到，其实也根本不代表数据已经成功送给客户端应用程序，比如对方可能发生资源不足的情况，导致AFD.SYS不能把数据拷贝给应用程序。另一个更要紧的问题是，在每个线程中每次只能进行一次发送调用，效率极其低下。

把SO_RCVBUF设为0，关闭AFD.SYS的接收缓冲区也不能让性能得到提升，这只会迫使接收到的数据在比Winsock更低的层次进行缓冲，当你发出receive调用时，同样要进行缓冲区拷贝，因此你本来想避免缓冲区拷贝的阴谋不会得逞。

现在我们应该清楚了，关闭缓冲区对于多数应用程序而言并不是什么好主意。只要要应用程序注意随时在某个连接上保持几个WSARecvs重叠调用，那么通常没有必要关闭接收缓冲区。如果AFD.SYS总是有由应用程序提供的缓冲区可用，那么它将没有必要使用内部缓冲区。

高性能的服务器应用程序可以关闭发送缓冲区，同时不会损失性能。不过，这样的应用程序必须十分小心，保证它总是发出多个重叠发送调用，而不是等待某个重叠发送结束了才发出下一个。如果应用程序是按一个发完再发下一个的顺序来操作，那浪费掉两次发送中间的空档时间，总之是要保证传输驱动程序在发送完一个缓冲区后，立刻可以转向另一个缓冲区。

资源的限制条件

在设计任何服务器应用程序时，其强健性是主要的目标。也就是说，

你的应用程序要能够应对任何突发的问题，例如并发客户请求数达到峰值、可用内存临时出现不足、以及其它短时间的现象。这就要求程序的设计者注意Windows NT和2000系统下的资源限制条件的问题，从容地处理突发性事件。

你可以直接控制的、最基本的资源就是网络带宽。通常，使用用户数据报协议(UDP)的应用程序都可能会比较注意带宽方面的限制，以最大限度地减少包的丢失。然而，在使用TCP连接时，服务器必须十分小心地控制好，防止网络带宽过载超过一定的时间，否则将需要重发大量的包或造成大量连接中断。关于带宽管理的方法应根据不同的应用程序而定，这超出了本文讨论的范围。

虚拟内存的使用也必须很小心地管理。通过谨慎地申请和释放内存，或者应用lookaside lists(一种高速缓存)技术来重新使用已分配的内存，将有助于控制服务器应用程序的内存开销(原文为“让服务器应用程序留下的脚印小一点”)，避免操作系统频繁地将应用程序申请的物理内存交换到虚拟内存中(原文为“让操作系统能够总是把更多的应用程序地址空间更多地保留在内存中”)。你也可以通过 SetWorkingSetSize()这个Win32 API让操作系统分配给你的应用程序更多的物理内存。

在使用Winsock时还可能碰到另外两个非直接的资源不足情况。一个是被锁定的内存页面的极限。如果你把AFD.SYS的缓冲关闭，当应用程序收发数据时，应用程序缓冲区的所有页面将被锁定到物理内存中。这是因为内核驱动程序需要访问这些内存，在此期间这些页面不能交换出去。如果操作系统需要给其它应用程序分配一些可分页的物理内存，而又没有足够的内存时就会发生问题。我们的目标是要防止写出一个病态的、锁定所有物理内存、让系统崩溃的程序。也就是说，你的程序锁定内存时，不要超出系统规定的内存分页极限。

在Windows NT和2000系统上，所有应用程序总共可以锁定的内存大约是物理内存的1/8(不过这只是一个大概的估计，不是你计算内存的依据)。如果你的应用程序不注意这一点，当你的发出太多的重叠收发调用，而且I/O没来得及完成时，就可能偶尔发生ERROR_INSUFFICIENT_RESOURCES的错误。在这种情况下你要避免过度锁定内存。同时要注意，系统会锁定包含你的缓冲区所在的整个内存页面，因此缓冲区靠近页边界时是有代价的(译者理解，缓冲区如果正好超过页面边界，那怕是1个字节，超出的这个字节所在的页面也会被锁定)。

另外一个限制是你的程序可能会遇到系统未分页池资源不足的情况。所谓未分页池是一块永远不被交换出去的内存区域，这块内存用来存储一些供各种内核组件访问的数据，其中有的内核组件是不能访问那些被交换出去的页面空间的。Windows NT和2000的驱动程序能够从这个特定的未分页池分配内存。

当应用程序创建一个套接字(或者是类似的打开某个文件)时，内核会从未分页池中分配一定数量的内存，而且在绑定、连接套接字时，内核又会从未分页池中再分配一些内存。当你注意观察这种行为时你将发现，如果你发出某些I/O请求时(例如收发数据)，你会从未分页池里再分配多一些内存(比如要追踪某个待决的 I/O操作，你可能需要给这个操作添加一个自定义结构，如前文所提及的)。最后这就可能会造成一定的问题，操作系统会限制未分页内存的用量。

在Windows NT和2000这两种操作系统上，给每个连接分配的未分页内存的具体数量是不同的，未来版本的Windows很可能也不同。为了使应用程序的生命期更长，你就不应该计算对未分页池内存的具体需求量。

你的程序必须防止消耗到未分页池的极限。当系统中未分页池剩余空间太小时，某些与你的应用程序毫无关系的内核驱动就会发疯，甚至造成系统崩溃，特别是当系统中有第三方设备或驱动程序时，更容易发生这样的惨剧(而且无法预测)。同时你还要记住，同一台电脑上还可能运行有其它同样消耗未分页池的其它应用程序，因此在设计你的应用程序时，对资源量的预估要特别保守和谨慎。

处理资源不足的问题是十分复杂的，因为发生上述情况时你不会收到特别的错误代码，通常你只能收到一般性的WSAENOBUFS或者ERROR_INSUFFICIENT_RESOURCES 错误。要处理这些错误，首先，把你的应用程序工作配置调整到合理的最大值(译者注：所谓工作配置，是指应用程序各部分运行中所需的内存用量，请参考 http://msdn.microsoft.com/msdnmag/issues/1000/Bugslayer/Bugslayer1000.asp ，关于内存优化，译者另有译文)，如果错误继续出现，那么注意检查是否是网络带宽不足的问题。之后，请确认你没有同时发出太多的收发调用。最后，如果还是收到资源不足的错误，那就很可能是遇到了未分页内存池不足的问题了。要释放未分页内存池空间，请关闭应用程序中相当部分的连接，等待系统自行渡过和修正这个瞬时的错误。

接受连接请求

服务器要做的最普通的事情之一就是接受来自客户端的连接请求。在套接字上使用重叠I/O接受连接的惟一API就是AcceptEx()函数。有趣的是，通常的同步接受函数accept()的返回值是一个新的套接字，而AcceptEx()函数则需要另外一个套接字作为它的参数之一。这是因为 AcceptEx()是一个重叠操作，所以你需要事先创建一个套接字(但不要绑定或连接它)，并把这个套接字通过参数传给AcceptEx()。以下是一小段典型的使用AcceptEx()的伪代码：

do {
    -等待上一个 AcceptEx 完成
    -创建一个新套接字并与完成端口进行关联
    -设置背景结构等等
    -发出一个 AcceptEx 请求
}while(TRUE);

对于Windows2000，Winsock提供了一些机制，帮助你判定AcceptEx的数量是否足够。这就是，在创建监听套接字时创建一个事件，通过WSAEventSelect()这个API并注册FD_ACCEPT事件通知来把套接字和这个事件关联起来。一旦系统收到一个连接请求，如果系统中没有AcceptEx()正在等待接受连接，那么上面的事件将收到一个信号。通过这个事件，你就可以判断你有没有发出足够的 AcceptEx()，或者检测出一个非正常的客户请求(下文述)。这种机制对Windows NT 4.0不适用。

使用AcceptEx()的一大好处是，你可以通过一次调用就完成接受客户端连接请求和接受数据(通过传送lpOutputBuffer参数)两件事情。也就是说，如果客户端在发出连接的同时传输数据，你的AcceptEx()调用在连接创建并接收了客户端数据后就可以立刻返回。这样可能是很有用的，但是也可能会引发问题，因为AcceptEx()必须等全部客户端数据都收到了才返回。具体来说，如果你在发出AcceptEx()调用的同时传递了lpOutputBuffer参数，那么AcceptEx()不再是一项原子型的操作，而是分成了两步：接受客户连接，等待接收数据。当缺少一种机制来通知你的应用程序所发生的这种情况：“连接已经建立了，正在等待客户端数据”，这将意味着有可能出现客户端只发出连接请求，但是不发送数据。如果你的服务器收到太多这种类型的连接时，它将拒绝连接更多的合法客户端请求。这就是黑客进行“拒绝服务”攻击的常见手法。

要预防此类攻击，接受连接的线程应该不时地通过调用getsockopt()函数(选项参数为 SO_CONNECT_TIME)来检查AcceptEx()里守候的套接字。getsockopt()函数的选项值将被设置为套接字被连接的时间，或者设置为-1(代表套接字尚未建立连接)。这时，WSAEventSelect()的特性就可以很好地利用来做这种检查。如果发现连接已经建立，但是很久都没有收到数据的情况，那么就应该终止连接，方法就是关闭作为参数提供给AcceptEx()的那个套接字。注意，在多数非紧急情况下，如果套接字已经传递给AcceptEx()并开始守候，但还未建立连接，那么你的应用程序不应该关闭它们。这是因为即使关闭了这些套接字，出于提高系统性能的考虑，在连接进入之前，或者监听套接字自身被关闭之前，相应的内核模式的数据结构也不会被干净地清除。

发出AcceptEx()调用的线程，似乎与那个进行完成端口关联操作、处理其它I/O完成通知的线程是同一个，但是，别忘记线程里应该尽力避免执行阻塞型的操作。Winsock2分层结构的一个副作用是调用socket()或WSASocket() API的上层架构可能很重要(译者不太明白原文意思，抱歉)。每个AcceptEx()调用都需要创建一个新套接字，所以最好有一个独立的线程专门调用AcceptEx()，而不参与其它I/O处理。你也可以利用这个线程来执行其它任务，比如事件记录。

有关AcceptEx()的最后一个注意事项：要实现这些API，并不需要其它提供商提供的Winsock2实现。这一点对微软特有的其它API也同样适用，比如TransmitFile()和GetAcceptExSockAddrs()，以及其它可能会被加入到新版Windows的API. 在Windows NT和2000上，这些API是在微软的底层提供者DLL(mswsock.dll)中实现的，可通过与mswsock.lib编译连接进行调用，或者通过WSAIoctl() (选项参数为SIO_GET_EXTENSION_FUNCTION_POINTER)动态获得函数的指针。

如果在没有事先获得函数指针的情况下直接调用函数(也就是说，编译时静态连接mswsock.lib，在程序中直接调用函数)，那么性能将很受影响。因为 AcceptEx()被置于Winsock2架构之外，每次调用时它都被迫通过WSAIoctl()取得函数指针。要避免这种性能损失，需要使用这些 API的应用程序应该通过调用WSAIoctl()直接从底层的提供者那里取得函数的指针。

参见下图套接字架构：



TransmitFile 和 TransmitPackets

Winsock 提供两个专门为文件和内存数据传输进行了优化的函数。其中TransmitFile()这个API函数在Windows NT 4.0 和 Windows 2000上都可以使用，而TransmitPackets()则将在未来版本的Windows中实现。

TransmitFile ()用来把文件内容通过Winsock进行传输。通常发送文件的做法是，先调用CreateFile()打开一个文件，然后不断循环调用ReadFile () 和WSASend ()直至数据发送完毕。但是这种方法很没有效率，因为每次调用ReadFile() 和 WSASend ()都会涉及一次从用户模式到内核模式的转换。如果换成TransmitFile()，那么只需要给它一个已打开文件的句柄和要发送的字节数，而所涉及的模式转换操作将只在调用CreateFile()打开文件时发生一次，然后TransmitFile()时再发生一次。这样效率就高多了。

TransmitPackets()比TransmitFile()更进一步，它允许用户只调用一次就可以发送指定的多个文件和内存缓冲区。函数原型如下：

BOOL TransmitPackets(
  SOCKET hSocket,                             
  LPTRANSMIT_PACKET_ELEMENT lpPacketArray,
  DWORD nElementCount,                
  DWORD nSendSize,                
  LPOVERLAPPED lpOverlapped,                  
  DWORD dwFlags                               
); 

typedef struct _TRANSMIT_PACKETS_ELEMENT { 
    DWORD dwElFlags; 
    DWORD cLength; 
    union {
        struct {
            LARGE_INTEGER     nFileOffset;
            HANDLE            hFile;
            };
            PVOID             pBuffer;
    };
} TRANSMIT_FILE_BUFFERS;

使用这两个API的另一个好处，是可以通过指定TF_REUSE_SOCKET和TF_DISCONNECT标志来重用套接字句柄。每当API完成数据的传输工作后，就会在传输层级别断开连接，这样这个套接字就又可以重新提供给AcceptEx()使用。采用这种优化的方法编程，将减轻那个专门做接受操作的线程创建套接字的压力(前文述及)。

这两个API也都有一个共同的弱点：Windows NT Workstation 或 Windows 2000 专业版中，函数每次只能处理两个调用请求，只有在Windows NT、Windows 2000服务器版、Windows 2000高级服务器版或 Windows 2000 Data Center中才获得完全支持。

放在一起看看

以上各节中，我们讨论了开发高性能的、大响应规模的应用程序所需的函数、方法和可能遇到的资源瓶颈问题。这些对你意味着什么呢？其实，这取决于你如何构造你的服务器和客户端。当你能够在服务器和客户端设计上进行更好地控制时，那么你越能够避开瓶颈问题。

来看一个示范的环境。我们要设计一个服务器来响应客户端的连接、发送请求、接收数据以及断开连接。那么，服务器将需要创建一个监听套接字，把它与某个完成端口进行关联，为每颗CPU创建一个工作线程。再创建一个线程专门用来发出AcceptEx()。我们知道客户端会在发出连接请求后立刻传送数据，所以如果我们准备好接收缓冲区会使事情变得更为容易。当然，不要忘记不时地轮询AcceptEx()调用中使用的套接字(使用SO_CONNECT_TIME选项参数)来确保没有恶意超时的连接。

该设计中有一个重要的问题要考虑，我们应该允许多少个AcceptEx()进行守候。这是因为，每发出一个AcceptEx()时我们都同时需要为它提供一个接收缓冲区，那么内存中将会出现很多被锁定的页面(前文说过了，每个重叠操作都会消耗一小部分未分页内存池，同时还会锁定所有涉及的缓冲区)。这个问题很难回答，没有一个确切的答案。最好的方法是把这个值做成可以调整的，通过反复做性能测试，你就可以得出在典型应用环境中最佳的值。

好了，当你测算清楚后，下面就是发送数据的问题了，考虑的重点是你希望服务器同时处理多少个并发的连接。通常情况下，服务器应该限制并发连接的数量以及等候处理的发送调用。因为并发连接数量越多，所消耗的未分页内存池也越多；等候处理的发送调用越多，被锁定的内存页面也越多(小心别超过了极限)。这同样也需要反复测试才知道答案。

对于上述环境，通常不需要关闭单个套接字的缓冲区，因为只在AcceptEx()中有一次接收数据的操作，而要保证给每个到来的连接提供接收缓冲区并不是太难的事情。但是，如果客户机与服务器交互的方式变一变，客户机在发送了一次数据之后，还需要发送更多的数据，在这种情况下关闭接收缓冲就不太妙了，除非你想办法保证在每个连接上都发出了重叠接收调用来接收更多的数据。

结论

开发大响应规模的Winsock服务器并不是很可怕，其实也就是设置一个监听套接字、接受连接请求和进行重叠收发调用。通过设置合理的进行守候的重叠调用的数量，防止出现未分页内存池被耗尽，这才是最主要的挑战。按照我们前面讨论的一些原则，你就可以开发出大响应规模的服务器应用程序。

DWORD dwStyle = m_ListCtrl.GetStyle();
dwStyle |= LVS_EX_CHECKBOXES;
m_ListCtrl.SetExtendedStyle(dwStyle);

2.让List Box有Check Box
首先，声明Control变量的时候用CCheckListBox代替CListBox。
然后，将List Box的Has Strings属性改为True；把Ower Draw属性改为Fixed。

void CSampleView:
OnDraw(CDC * pDC)
{
if( :: SHGetFileInfo(_T("c:\\pwin95\\notepad.exe"),0,
&stFileInfo,sizeof(stFileInfo),SHGFI_ICON))
{
pDC ->DrawIcon(10,10,stFileInfo.hIcon)
}
}
Example(2):同样功能,Use ExtractIcon Function
void CSampleView:: OnDraw(CDC *pDC)
{
HICON hIcon=:: ExtractIcon(AfxGetInstanceHandle(),_T
("NotePad.exe"),0)
if (hIcon &&hIcon!=(HICON)-1)
pDC->DrawIcon(10,10,hIcon)
}

    说明: 获得notepad.exe的路径正规上来说用GetWindowsDirectory函数得到, 如果是调用 win95下的画笔，应该用访问注册表的方法获得其路径，要作成一个比较考究的程序，考虑应该全面点.

#include <stdio.h>
#include <winsock2.h>

#define TCP

#pragma comment(lib,"ws2_32.lib")

int main( int argc ,char* argv[])
{
 WSAData wsaData;

 WSAStartup(WINSOCK_VERSION,&wsaData);
 DWORD begin,finish;

 struct timeval tv;
 tv.tv_sec = 5000;
 tv.tv_usec = 0;
 int optlen = sizeof(struct timeval);

 //
 SOCKET sock = socket(PF_INET,SOCK_STREAM,0);

 struct sockaddr_in to;
 int len = sizeof(struct sockaddr_in);
 memset(&to,0,len);

 to.sin_addr.s_addr = inet_addr("202.108.9.39");;
 to.sin_port = htons(80);
 to.sin_family = AF_INET;

 if ( connect(sock,(struct sockaddr*)&to,len) == SOCKET_ERROR )
 {
  closesocket(sock);
  return 0;
 }

 //设置超时值为tv
 if ( setsockopt(sock,SOL_SOCKET,SO_RCVTIMEO,(char*)&tv,optlen) ==
  SOCKET_ERROR)
 {
  closesocket(sock);
  return 0;
 }

 char buf[100];
 if ( recv(sock,buf,100,0) == SOCKET_ERROR )
 {
  printf("d");
 }

 return 0;
}

保存文件对话框
const char pszFilter[] = _T("EXE Files (*.txt)|*.txt||");
CFileDialog dlgSave( FALSE,   //FALSE为保存
  _T(".txt"), //自动加上的扩展名
  _T("Output.txt"),  //默认保存的文件名
  OFN_HIDEREADONLY | OFN_OVERWRITEPROMPT,
  pszFilter, this);



目录选择对话框

 BROWSEINFO bi;
 char szPathName[MAX_PATH];
 char szTitle[] = "选择路径";
 ZeroMemory(&bi, sizeof(BROWSEINFO));
 
 bi.hwndOwner = GetSafeHwnd();
 bi.pszDisplayName = szPathName;
 bi.lpszTitle = szTitle;
 bi.ulFlags = 0x0040 ;
 CString str;
CString strDir;  //选择的目录

 LPITEMIDLIST idl = SHBrowseForFolder(&bi);
 if(idl == NULL)
 {
  strDir= "";
  return;
 }
 
 SHGetPathFromIDList(idl, str.GetBuffer(MAX_PATH * 2));
 str.ReleaseBuffer();
 if(str != "" && str.GetAt(str.GetLength() - 1) != '\\')
  str += "\\";
 strDir = str;

CRect rect;
//IDC_STATIC_PATH是显示字符串的static控件的ID, 注意控件的要设为不可见
GetDlgItem(IDC_STATIC_PATH)->GetWindowRect(rect);
ScreenToClient(rect);

dc.DrawText(m_strCorePath, -1, rect, DT_LEFT | DT_PATH_ELLIPSIS | DT_VCENTER | DT_SINGLELINE);
dc.SelectObject(pOldFont);

窗口半透明
HMODULE hUser32 = GetModuleHandle("user32.dll");
MySetLayeredWindowAttributes = (lpfnSetLayeredWindowAttributes)GetProcAddress(hUser32,"SetLayeredWindowAttributes");
if(MySetLayeredWindowAttributes == NULL)
{
 AfxMessageBox("载入系统dll失败,程序即将退出!");
 exit(0);
}

::SetWindowLong(GetSafeHwnd(), GWL_EXSTYLE, GetWindowLong(GetSafeHwnd(), GWL_EXSTYLE) ^ WS_EX_LAYERED);
MySetLayeredWindowAttributes(GetSafeHwnd(), 0,
 130, //这个参数是控制窗口透明的层度, 为0时窗口全透明,包括标题栏. 为255时,不透明
 LWA_ALPHA);//LWA_COLORKEY
FreeLibrary(hUser32);

使对话框窗口的客户区全透明
COLORREF maskColor= 14215660; 这是颜色掩码,与这个颜色相同的将不被显示出来
SetWindowLong(GetSafeHwnd(), GWL_EXSTYLE, GetWindowLong(GetSafeHwnd(), GWL_EXSTYLE) | WS_EX_LAYERED);
MySetLayeredWindowAttributes(GetSafeHwnd(), maskColor, 10, LWA_COLORKEY);

using namespace std;

void main()
{
 ifstream inputFile("Data.txt");
 if(!inputFile.is_open())
           return;
//这条语句在VC6下编译报错,VC6对模板支持不够
 string str((istreambuf_iterator<char>(inputFile)), istreambuf_iterator<char>());
 inputFile.close();
}

bool DeliverResource(const CString& strDestPath, const char * pszID, const char * pszType)
{
 HRSRC hRsrc = FindResource(NULL, pszID, pszType);
 if(NULL == hRsrc)
  return false;
 DWORD dwSize = SizeofResource(NULL, hRsrc);
 if(0 == dwSize)
  return false;
 HGLOBAL hGlobal = LoadResource(NULL, hRsrc);
 if(NULL == hGlobal)
  return false;
 LPVOID pBuffer = LockResource(hGlobal);
 if(NULL == pBuffer)
  return false;

 tool::CreateMidDir(strDestPath);
 FILE *fp = fopen(strDestPath, "wb");
 DWORD dwRemain = dwSize;
 while(dwRemain > 0)
 {
  dwRemain -= fwrite(pBuffer, sizeof(char), dwRemain, fp);
 }
 fclose(fp);
 return true;
}

 DWORD dwLength = GetFileSize(hFile, NULL);
 //创建内存映射对象,内存映射文件的大小 = 文件长度 + (WCHAR)'\0'
 //因为我们要在文件的末尾加上一个字符串的结束符'\0', 当我们将这个文件映射到内存中时,我们就可以像操作字符串一样地来操作文件了
 const HANDLE hFileMap = CreateFileMapping(
  hFile, NULL, PAGE_READWRITE, 0,
  dwLength + sizeof(WCHAR),
  NULL);
 
 char * pFile = (char *)MapViewOfFile(hFileMap, FILE_MAP_WRITE, 0, 0, 0);
 pFile[dwLength / sizeof(char)] = '\0';
 
 //现在对文件的操作就变成了对一字符串pFile的操作了,所有的字符串函数都能
 //对pFile这个字符串进行操作, 而操作的结果则会被保存到文件中去(但是并不
是改变pFile
 //中的内容后会立刻写到文件中去,但是在调用UnmapViewOfFile()后,保证先前对pFile的修改全部保存到文件中了)
 //...........
 //statement();
 //............

 UnmapViewOfFile(pFile);
 CloseHandle(hFileMap);

 //我们改变了文件的长度,因此要重新设置文件的结束符以删除留在文件尾部的多余内容(比如删除我们先前加到文件末尾的'\0'字符)
 SetFilePointer(hFile,dwLength , NULL, FILE_BEGIN);
 SetEndOfFile(hFile);  //设定当前文件指针所在处为文件结束处.该处后面的内容将被删除
 CloseHandle(hFile);
 return true;
}

HHOOK g_hHook = NULL;

首先要安装钩子
g_hHook = SetWindowsHookEx(WH_KEYBOARD_LL, HookFun, GetModuleHandle(NULL), NULL);
if(g_hHook == NULL)
 AfxMessageBox("hook failure!");

在程序结束时要卸载钩子
UnhookWindowsHookEx(g_hHook);

钩子函数的实现
LRESULT CALLBACK HookFun(int nCode, WPARAM wParam, LPARAM lParam)
{
  CWPSTRUCT* p = (CWPSTRUCT*) lParam;
 if (nCode == HC_ACTION)
 { 
  switch (wParam) //wParam中是消息ID
  { 
  case WM_KEYDOWN: 
   {  
      if(p->lParam == 'l' || p->lParam == 'L') 
      {
           // 'l' 键被按下 
            //do somthing
       }
    
    if(p->lParam == VK_ESCAPE)
    {//用户按下了Esc
      //do somthing
    }  
  } 
 }
 return CallNextHookEx(NULL, nCode, wParam, lParam);
}

从dll中导出一个类,  使用这个dll中类的可执行代码工程必须和这个dll工程用的是同一编译器
否则这个dll将不可用
*/

class CMyAlg
{
public:
 __declspec(dllimport) int Add(int a, int b);
};


//===================================
//MyAlg.cpp
//===================================
#include "MyAlg.h"
int CMyAlg::Add(int a, int b)
{
 return (a + b);
}





//===================================
//alg.h
//===================================

/*
显示装载的dll

从dll中导出一人函数和一个变量, 这个不会出现像导出类所碰到的问题, 要以C
风格的型式导出
*/
extern "C" __declspec(dllimport) int Add(int a, int b);
extern "C" __declspec(dllimport) int g_nValue;







//===================================
//test.cpp  测试前面写好的dll
//===================================

#include <stdio.h>

#define   EXPLICIT_LOAD

#ifdef EXPLICIT_LOAD //定义了显示方法加载DLL
#include <windows.h>
#endif

#ifdef IMPLICIT_LOAD //定义了隐示方法加载DLL
#include "MyAlg.h"
#include "alg.h"
#pragma comment(lib, "Class.lib") //dll中导出一个类
#pragma comment(lib, "Win32Dll.lib")//dll中导出一个函数和变量
#endif

void main(void)
{
#ifdef IMPLICIT_LOAD
//使用隐示方法加载DLL,可以调用dll中导出的函数、变量和类
 CMyAlg alg;
 printf("使用隐示方法加载DLL\n");
 printf("CMyAlg::Add(%d, %d) = %d, \n", 1, 2, alg.Add(1, + 2));
 printf("Add(%d, %d) = %d, g_nValue = %d\n\n", 1, 2, Add(1, 2), g_nValue);
#endif

#ifdef EXPLICIT_LOAD 
//使用显示的方法加载DLL，只能调用dll中以C风格导出的函数
 printf("使用显示的方法加载DLL\n");
 HINSTANCE hIns = LoadLibrary("Win32Dll.dll");
 if(hIns = NULL)
 {
  printf("Load dll failure!\n");
  return;
 }
 
 typedef int(* pAdd)(int, int);
 pAdd pfun = (pAdd)GetProcAddress(hIns, "Add");
 printf("pfun(1, 2) = %d, pfun(1,2)\n");

 FreeLibrary(hIns);
#endif

 getchar();
}

2．vector<char>来储存二进制流


3．vector 的at方法会进行边界检查，[]操作符则不会


4.从ifstream读出一行到string，使用std::getline(ifstream的成员函数getline做不到)

5.警惕string的引用记数技术实现带来的潜在问题
string greet("Hello, world");
string hi(greet);
char *ptr = (char *)hi.c_str();
ptr[0] = 'h';
两个字符串都被修改。

在多线程之间引用多个有关系的string，可能导致引用计数失效，造成多次删除，或者memory leak.
保险的做法是:
string s1("hello") ; string s2 (s1.c_str()); //force copy

避免iterator失效，不提取无效的iterator
比如：
vector<int> iv;
vector<int>::iterator end = iv .end();
for(int i=0;i<10;++i)
    iv.insert(end,i);
会crash ,因为end指针，随着insert后可能失效
改为：
vector<int> iv;
for(int i=0;i<10;++i)
    iv.insert(iv.end(),i);
或者：
vector<int> iv;
for(int i=0;i<10;++i)
    iv.push_back(i); //prefer

 DWORD dwType;
 const int nTimeOut = 2000;
 session.SetOption(INTERNET_OPTION_CONNECT_TIMEOUT, nTimeOut); //重试之间的等待延时
 session.SetOption(INTERNET_OPTION_CONNECT_RETRIES, 1);   //重试次数
 char* pszBuffer = NULL;  

 try
 {
  AfxParseURL(strFileURLInServer, dwType, strServer, strObject, wPort);
  pHttpConnection = session.GetHttpConnection(strServer, wPort);
  pHttpFile = pHttpConnection->OpenRequest(CHttpConnection::HTTP_VERB_GET, strObject);
  if(pHttpFile->SendRequest() == FALSE)
   return false;
  DWORD dwStateCode;

  pHttpFile->QueryInfoStatusCode(dwStateCode);
  if(dwStateCode == HTTP_STATUS_OK)
  {
    HANDLE hFile = CreateFile(strFileLocalFullPath, GENERIC_WRITE,
         FILE_SHARE_WRITE, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL,
         NULL);  //创建本地文件
   if(hFile == INVALID_HANDLE_VALUE)
   {
    pHttpFile->Close();
    pHttpConnection->Close();
    session.Close();
    return false;
   }
 
   char szInfoBuffer[1000];  //返回消息
   DWORD dwFileSize = 0;   //文件长度
   DWORD dwInfoBufferSize = sizeof(szInfoBuffer);
   BOOL bResult = FALSE;
   bResult = pHttpFile->QueryInfo(HTTP_QUERY_CONTENT_LENGTH,
           (void*)szInfoBuffer,&dwInfoBufferSize,NULL);

   dwFileSize = atoi(szInfoBuffer);
   const int BUFFER_LENGTH = 1024 * 10;
   pszBuffer = new char[BUFFER_LENGTH];  //读取文件的缓冲
   DWORD dwWrite, dwTotalWrite;
   dwWrite = dwTotalWrite = 0;
   UINT nRead = pHttpFile->Read(pszBuffer, BUFFER_LENGTH); //读取服务器上数据

   while(nRead > 0)
   {
    WriteFile(hFile, pszBuffer, nRead, &dwWrite, NULL);  //写到本地文件
    dwTotalWrite += dwWrite;
    nRead = pHttpFile->Read(pszBuffer, BUFFER_LENGTH);
   }

   delete[]pszBuffer;
   pszBuffer = NULL;
   CloseHandle(hFile);
  }
  else
  {
   delete[]pszBuffer;
   pszBuffer = NULL;
   if(pHttpFile != NULL)
   {
    pHttpFile->Close();
    delete pHttpFile;
    pHttpFile = NULL;
   }
   if(pHttpConnection != NULL)
   {
    pHttpConnection->Close();
    delete pHttpConnection;
    pHttpConnection = NULL;
   }
   session.Close();
    return false;
  }
 }
 catch(...)
 {
  delete[]pszBuffer;
  pszBuffer = NULL;
  if(pHttpFile != NULL)
  {
   pHttpFile->Close();
   delete pHttpFile;
   pHttpFile = NULL;
  }
  if(pHttpConnection != NULL)
  {
   pHttpConnection->Close();
   delete pHttpConnection;
   pHttpConnection = NULL;
  }
  session.Close();
  return false;
 }

 if(pHttpFile != NULL)
  pHttpFile->Close();
 if(pHttpConnection != NULL)
  pHttpConnection->Close();
 session.Close();
 return true;
}

2、上传文件
UploadFile(LPCTSTR strURL, //负责接收上传操作的页面的URL
LPCTSTR strLocalFileName)  //待上传的本地文件路径
{
 ASSERT(strURL != NULL && strLocalFileName != NULL);

 BOOL bResult = FALSE;
 DWORD dwType = 0;
 CString strServer;
 CString strObject;
 INTERNET_PORT wPort = 0;
 DWORD dwFileLength = 0;
 char * pFileBuff = NULL;

 CHttpConnection * pHC = NULL;
 CHttpFile * pHF = NULL;
 CInternetSession cis;

 bResult =  AfxParseURL(strURL, dwType, strServer, strObject, wPort);
 if(!bResult)
  return FALSE;
 CFile file;
 try
 {
  if(!file.Open(strLocalFileName, CFile::shareDenyNone | CFile::modeRead))
   return FALSE;
  dwFileLength = file.GetLength();
  if(dwFileLength <= 0)
   return FALSE;
  pFileBuff = new char[dwFileLength];
  memset(pFileBuff, 0, sizeof(char) * dwFileLength);
  file.Read(pFileBuff, dwFileLength);

  const int nTimeOut = 5000;
  cis.SetOption(INTERNET_OPTION_CONNECT_TIMEOUT, nTimeOut); //联接超时设置
  cis.SetOption(INTERNET_OPTION_CONNECT_RETRIES, 1);  //重试1次
  pHC = cis.GetHttpConnection(strServer, wPort);  //取得一个Http联接

  pHF = pHC->OpenRequest(CHttpConnection::HTTP_VERB_POST, strObject);
  if(!pHF->SendRequest(NULL, 0, pFileBuff, dwFileLength))
  {
   delete[]pFileBuff;
   pFileBuff = NULL;
   pHF->Close();
   pHC->Close();
   cis.Close();
   return FALSE;
  }
  DWORD dwStateCode = 0;
  pHF->QueryInfoStatusCode(dwStateCode);

  if(dwStateCode == HTTP_STATUS_OK)
   bResult = TRUE;
 }

 catch(CInternetException * pEx)
 {
  char sz[256] = "";
  pEx->GetErrorMessage(sz, 25);
  CString str;
  str.Format("InternetException occur!\r\n%s", sz);
  AfxMessageBox(str);
 }
 catch(CFileException& fe)
 {
  CString str;
  str.Format("FileException occur!\r\n%d", fe.m_lOsError);
  AfxMessageBox(str);
 }
 catch(...)
 {
  DWORD dwError = GetLastError();
  CString str;
  str.Format("Unknow Exception occur!\r\n%d", dwError);
  AfxMessageBox(str);
 }

 delete[]pFileBuff;
 pFileBuff = NULL;
 file.Close();
 pHF->Close();
 pHC->Close();
 cis.Close();
 return bResult;
}