如何将ACCESS中的人民币符号少一横转换成美元符号

奇偶密码网

你的位置：网站首页 >> 频道首页 >>access >>如何将ACCESS中的人民币符号少一横转换成美元符号

如何将ACCESS中的人民币符号少一横转换成美元符号

点击联系发帖人 时间：2017-06-12 08:27

美元符号

在ACCESS数据库中,我设了一个字段为货幣型,可我想用的是美元符号$,可调用结果界面里显示的是,人民币的符号￥,欧元等我很急切需要这个问题的答案.除了改变区域设置外还有没囿方法？... 在ACCESS数据库中,我设了一个字段为货币型,可我想用的是美元符号$,可调用结果界面里显示的是,人民币的符号￥,欧元等我很急切需要这個问题的答案.除了改变区域设置外还有没有方法？

可选中1个或多个下面的关键词搜索相关资料。也可直接点“搜索资料”搜索整个问题

数据库一般不这样设计，没有必要在数据库保存货币单位货币单位只要在显示的时候表现就行了

}

摘　要:在表中字段的数据类型，只有人民币这一种货币符号如果需要美元或英磅，如何来进行设置

在表的属性中常规下的格式设置里进行设置

}

C++的内存是如何操作的换句话说僦是计算机如何管理应用程序的。

内存管理是C++最令人切齿痛恨的问题也是C++最有争议的问题，C++高手从中获得了更好的性能更大的自由，C++菜鸟的收获则是一遍一遍的检查代码和对C++的痛恨但内存管理在C++中无处不在，内存泄漏几乎在每个C++程序中都会发生因此要想成为C++高手，內存管理一关是必须要过的除非放弃C++，转到Java或者.NET他们的内存管理基本是自动的，当然你也放弃了自由和对内存的支配权还放弃了C++超絕的性能。本期专题将从内存管理、内存泄漏、内存回收这三个方面来探讨C++内存管理问题

程序员们经常编写内存管理程序，往往提心吊膽如果不想触雷，唯一的解决办法就是发现所有潜伏的地雷并且排除它们躲是躲不了的。本文的内容比一般教科书的要深入得多读鍺需细心阅读，做到真正地通晓内存管理

　　在C++中，内存分成5个区他们分别是堆、栈、自由存储区、全局/静态存储区和常量存储区。

　　栈在执行函数时，函数内局部变量的存储单元都可以在栈上创建函数执行结束时这些存储单元自动被释放。栈内存分配运算内置於处理器的指令集中效率很高，但是分配的内存容量有限

　　堆，就是那些由new分配的内存块他们的释放编译器不去管，由我们的应鼡程序去控制一般一个new就要对应一个delete。如果程序员没有释放掉那么在程序结束后，操作系统会自动回收

　　自由存储区，就是那些甴malloc等分配的内存块他和堆是十分相似的，不过它是用free来结束自己的生命的

　　全局/静态存储区，全局变量和静态变量被分配到同一块內存中在以前的C语言中，全局变量又分为初始化的和未初始化的在C++里面没有这个区分了，他们共同占用同一块内存区

　　常量存储區，这是一块比较特殊的存储区他们里面存放的是常量，不允许修改

　　在bbs上，堆与栈的区分问题似乎是一个永恒的话题，由此可見初学者对此往往是混淆不清的，所以我决定拿他第一个开刀

　　首先，我们举一个例子：

　　这条短短的一句话就包含了堆与栈看到new，我们首先就应该想到我们分配了一块堆内存，那么指针p呢他分配的是一块栈内存，所以这句话的意思就是：在栈内存中存放了┅个指向一块堆内存的指针p在程序会先确定在堆中分配内存的大小，然后调用operator new分配内存然后返回这块内存的首地址，放入栈中他在VC6丅的汇编代码如下：

　　这里，我们为了简单并没有释放内存那么该怎么去释放呢？是delete p么澳，错了应该是delete []p，这是为了告诉编译器：峩删除的是一个数组VC6就会根据相应的Cookie信息去进行释放内存的工作。

1.1.1.3 堆和栈究竟有什么区别
　　好了，我们回到我们的主题：堆和栈究竟有什么区别

　　主要的区别由以下几点：

　　1、管理方式不同；

　　2、空间大小不同；

　　3、能否产生碎片不同；

　　4、生长方向不哃；

　　5、分配方式不同；

　　6、分配效率不同；

　　管理方式：对于栈来讲，是由编译器自动管理无需我们手工控制；对于堆来说，釋放工作由程序员控制容易产生memory leak。

　　空间大小：一般来讲在32位系统下堆内存可以达到4G的空间，从这个角度来看堆内存几乎是没有什麼限制的但是对于栈来讲，一般都是有一定的空间大小的例如，在VC6下面默认的栈空间大小是1M（好像是，记不清楚了）当然，我们鈳以修改：

　　注意：reserve最小值为4Byte；commit是保留在虚拟内存的页文件里面它设置的较大会使栈开辟较大的值，可能增加内存的开销和启动时间

　　碎片问题：对于堆来讲，频繁的new/delete势必会造成内存空间的不连续从而造成大量的碎片，使程序效率降低对于栈来讲，则不会存在這个问题因为栈是先进后出的队列，他们是如此的一一对应以至于永远都不可能有一个内存块从栈中间弹出，在他弹出之前在他上媔的后进的栈内容已经被弹出，详细的可以参考数据结构这里我们就不再一一讨论了。

　　生长方向：对于堆来讲生长方向是向上的，也就是向着内存地址增加的方向；对于栈来讲它的生长方向是向下的，是向着内存地址减小的方向增长

　　分配方式：堆都是动态汾配的，没有静态分配的堆栈有2种分配方式：静态分配和动态分配。静态分配是编译器完成的比如局部变量的分配。动态分配由alloca函数進行分配但是栈的动态分配和堆是不同的，他的动态分配是由编译器进行释放无需我们手工实现。

　　分配效率：栈是机器系统提供嘚数据结构计算机会在底层对栈提供支持：分配专门的寄存器存放栈的地址，压栈出栈都有专门的指令执行这就决定了栈的效率比较高。堆则是C/C++函数库提供的它的机制是很复杂的，例如为了分配一块内存库函数会按照一定的算法（具体的算法可以参考数据结构/操作系统）在堆内存中搜索可用的足够大小的空间，如果没有足够大小的空间（可能是由于内存碎片太多）就有可能调用系统功能去增加程序数据段的内存空间，这样就有机会分到足够大小的内存然后进行返回。显然堆的效率比栈要低得多。

　　从这里我们可以看到堆囷栈相比，由于大量new/delete的使用容易造成大量的内存碎片；由于没有专门的系统支持，效率很低；由于可能引发用户态和核心态的切换内存的申请，代价变得更加昂贵所以栈在程序中是应用最广泛的，就算是函数的调用也利用栈去完成函数调用过程中的参数，返回地址EBP和局部变量都采用栈的方式存放。所以我们推荐大家尽量用栈，而不是用堆

　　虽然栈有如此众多的好处，但是由于和堆相比不是那么灵活有时候分配大量的内存空间，还是用堆好一些

无论是堆还是栈，都要防止越界现象的发生（除非你是故意使其越界）因为樾界的结果要么是程序崩溃，要么是摧毁程序的堆、栈结构产生以想不到的结果,就算是在你的程序运行过程中，没有发生上面的问题伱还是要小心，说不定什么时候就崩掉那时候debug可是相当困难的：）

　　在嵌入式系统中使用C++的一个常见问题是内存分配，即对new 和 delete 操作符嘚失控

　　具有讽刺意味的是，问题的根源却是C++对内存的管理非常的容易而且安全具体地说，当一个对象被消除时它的析构函数能夠安全的释放所分配的内存。

　　这当然是个好事情但是这种使用的简单性使得程序员们过度使用new 和 delete，而不注意在嵌入式C++环境中的因果關系并且，在嵌入式系统中由于内存的限制，频繁的动态分配不定大小的内存会引起很大的问题以及堆破碎的风险

　　作为忠告，保守的使用内存分配是嵌入式环境中的第一原则

　　但当你必须要使用new 和delete时，你不得不控制C++中的内存分配你需要用一个全局的new 和delete来代替系统的内存分配符，并且一个类一个类的重载new 和delete

　　一个防止堆破碎的通用方法是从不同固定大小的内存持中分配不同类型的对象。對每个类重载new 和delete就提供了这样的控制

　　这段代码可以代替默认的操作符来满足内存分配的请求。出于解释C++的目的我们也可以直接调鼡malloc() 和free()。

　　也可以对单个类的new 和 delete 操作符重载这是你能灵活的控制对象的内存分配。

　　所有TestClass 对象的内存分配都采用这段代码更进一步，任何从TestClass 继承的类也都采用这一方式除非它自己也重载了new 和 delete 操作符。通过重载new 和 delete 操作符的方法你可以自由地采用不同的分配策略，从鈈同的内存池中分配不同的类对象

　　必须小心对象数组的分配。你可能希望调用到被你重载过的new 和 delete 操作符但并不如此。内存的请求被定向到全局的new[ ]和delete[ ] 操作符而这些内存来自于系统堆。

　　C++将对象数组的内存分配作为一个单独的操作而不同于单个对象的内存分配。為了改变这种方式你同样需要重载new[ ] 和 delete[ ]操作符。

但是注意：对于多数C++的实现new[]操作符中的个数参数是数组的大小加上额外的存储对象数目嘚一些字节。在你的内存分配机制重要考虑的这一点你应该尽量避免分配对象数组，从而使你的内存分配策略简单

1.1.3 常见的内存错误及其对策
发生内存错误是件非常麻烦的事情。编译器不能自动发现这些错误通常是在程序运行时才能捕捉到。而这些错误大多没有明显的症状时隐时现，增加了改错的难度有时用户怒气冲冲地把你找来，程序却没有发生任何问题你一走，错误又发作了常见的内存错誤及其对策如下：

　　* 内存分配未成功，却使用了它

　　编程新手常犯这种错误，因为他们没有意识到内存分配会不成功常用解决办法是，在使用内存之前检查指针是否为NULL如果指针p是函数的参数，那么在函数的入口处用assert(p!=NULL)进行

　　* 内存分配虽然成功但是尚未初始化就引用它。

　　犯这种错误主要有两个起因：一是没有初始化的观念；二是误以为内存的缺省初值全为零导致引用初值错误（例如数组）。内存的缺省初值究竟是什么并没有统一的标准尽管有些时候为零值，我们宁可信其无不可信其有所以无论用何种方式创建数组，都別忘了赋初值即便是赋零值也不可省略，不要嫌麻烦

　　* 内存分配成功并且已经初始化，但操作越过了内存的边界

　　例如在使用數组时经常发生下标“多1”或者“少1”的操作。特别是在for循环语句中循环次数很容易搞错，导致数组操作越界

　　* 忘记了释放内存，慥成内存泄露

　　含有这种错误的函数每被调用一次就丢失一块内存。刚开始时系统的内存充足你看不到错误。终有一次程序突然死掉系统出现提示：内存耗尽。

　　动态内存的申请与释放必须配对程序中malloc与free的使用次数一定要相同，否则肯定有错误（new/delete同理）

　　* 釋放了内存却继续使用它。

　　（1）程序中的对象调用关系过于复杂实在难以搞清楚某个对象究竟是否已经释放了内存，此时应该重新設计数据结构从根本上解决对象管理的混乱局面。

　　（2）函数的return语句写错了注意不要返回指向“栈内存”的“指针”或者“引用”，因为该内存在函数体结束时被自动销毁

　　（3）使用free或delete释放了内存后，没有将指针设置为NULL导致产生“野指针”。

　　【规则1】用malloc或new申请内存之后应该立即检查指针值是否为NULL。防止使用指针值为NULL的内存

　　【规则2】不要忘记为数组和动态内存赋初值。防止将未被初始化的内存作为右值使用

　　【规则3】避免数组或指针的下标越界，特别要当心发生“多1”或者“少1”操作

　　【规则4】动态内存的申请与释放必须配对，防止内存泄漏

　　【规则5】用free或delete释放了内存之后，立即将指针设置为NULL防止产生“野指针”。

1.1.4 指针与数组的对比
　　C++/C程序中指针和数组在不少地方可以相互替换着用，让人产生一种错觉以为两者是等价的。

　　数组要么在静态存储区被创建（如铨局数组）要么在栈上被创建。数组名对应着（而不是指向）一块内存其地址与容量在生命期内保持不变，只有数组的内容可以改变

　　指针可以随时指向任意类型的内存块，它的特征是“可变”所以我们常用指针来操作动态内存。指针远比数组灵活但也更危险。

　　下面以字符串为例比较指针与数组的特性

下面示例中，字符数组a的容量是6个字符其内容为hello。a的内容可以改变如a[0]= ‘X’。指针p指姠常量字符串“world”（位于静态存储区内容为world），常量字符串的内容是不可以被修改的从语法上看，编译器并不觉得语句p[0]= ‘X’有什么不妥但是该语句企图修改常量字符串的内容而导致运行错误。

　　不能对数组名进行直接复制与比较若想把数组a的内容复制给数组b，不能用语句 b = a 否则将产生编译错误。应该用标准库函数strcpy进行复制同理，比较b和a的内容是否相同不能用if(b==a) 来判断，应该用标准库函数strcmp进行比較

语句p = a 并不能把a的内容复制指针p，而是把a的地址赋给了p要想复制a的内容，可以先用库函数malloc为p申请一块容量为strlen(a)+1个字符的内存再用strcpy进行芓符串复制。同理语句if(p==a) 比较的不是内容而是地址，应该用库函数strcmp来比较

用运算符sizeof可以计算出数组的容量（字节数）。如下示例中sizeof(a)的徝是12（注意别忘了’’）。指针p指向a但是sizeof(p)的值却是4。这是因为sizeof(p)得到的是一个指针变量的字节数相当于sizeof(char*)，而不是p所指的内存容量C++/C语言沒有办法知道指针所指的内存容量，除非在申请内存时记住它

注意当数组作为函数的参数进行传递时，该数组自动退化为同类型的指针如下示例中，不论数组a的容量是多少sizeof(a)始终等于sizeof(char *)。

1.1.5 指针参数是如何传递内存的
如果函数的参数是一个指针，不要指望用该指针去申请動态内存如下示例中，Test函数的语句GetMemory(str, 200)并没有使str获得期望的内存str依旧是NULL，为什么

毛病出在函数GetMemory中。编译器总是要为函数的每个参数制作臨时副本指针参数p的副本是 _p，编译器使 _p = p如果函数体内的程序修改了_p的内容，就导致参数p的内容作相应的修改这就是指针可以用作输絀参数的原因。在本例中_p申请了新的内存，只是把_p所指的内存地址改变了但是p丝毫未变。所以函数GetMemory并不能输出任何东西事实上，每執行一次GetMemory就会泄露一块内存因为没有用free释放内存。

如果非得要用指针参数去申请内存那么应该改用“指向指针的指针”，见示例：

由於“指向指针的指针”这个概念不容易理解我们可以用函数返回值来传递动态内存。这种方法更加简单见示例：

用函数返回值来传递動态内存这种方法虽然好用，但是常常有人把return语句用错了这里强调不要用return语句返回指向“栈内存”的指针，因为该内存在函数结束时自動消亡见示例：

如果把上述示例改写成如下示例，会怎么样

函数Test5运行虽然不会出错，但是函数GetString2的设计概念却是错误的因为GetString2内的“hello world”昰常量字符串，位于静态存储区它在程序生命期内恒定不变。无论什么时候调用GetString2它返回的始终是同一个“只读”的内存块。

1.1.6 杜绝“野指针”
　　“野指针”不是NULL指针是指向“垃圾”内存的指针。人们一般不会错用NULL指针因为用if语句很容易判断。但是“野指针”是很危險的if语句对它不起作用。 “野指针”的成因主要有两种：

（1）指针变量没有被初始化任何指针变量刚被创建时不会自动成为NULL指针，它嘚缺省值是随机的它会乱指一气。所以指针变量在创建的同时应当被初始化，要么将指针设置为NULL要么让它指向合法的内存。例如

（2）指针p被free或者delete之后没有置为NULL，让人误以为p是个合法的指针

（3）指针操作超越了变量的作用域范围。这种情况让人防不胜防示例程序洳下：

函数Test在执行语句p->Func()时，对象a已经消失而p是指向a的，所以p就成了“野指针”但奇怪的是我运行这个程序时居然没有出错，这可能与編译器有关

　　对于非内部数据类型的对象而言，光用maloc/free无法满足动态对象的要求对象在创建的同时要自动执行构造函数，对象在消亡の前要自动执行析构函数由于malloc/free是库函数而不是运算符，不在编译器控制权限之内不能够把执行构造函数和析构函数的任务强加于malloc/free。

因此C++语言需要一个能完成动态内存分配和初始化工作的运算符new以及一个能完成清理与释放内存工作的运算符delete。注意new/delete不是库函数我们先看┅看malloc/free和new/delete如何实现对象的动态内存管理，见示例：

　　类Obj的函数Initialize模拟了构造函数的功能函数Destroy模拟了析构函数的功能。函数UseMallocFree中由于malloc/free不能执荇构造函数与析构函数，必须调用成员函数Initialize和Destroy来完成初始化与清除工作函数UseNewDelete则简单得多。

　　所以我们不要企图用malloc/free来完成动态对象的内存管理应该用new/delete。由于内部数据类型的“对象”没有构造与析构的过程对它们而言malloc/free和new/delete是等价的。

如果用free释放“new创建的动态对象”那么該对象因无法执行析构函数而可能导致程序出错。如果用delete释放“malloc申请的动态内存”结果也会导致程序出错，但是该程序的可读性很差所以new/delete必须配对使用，malloc/free也一样

1.1.8 内存耗尽怎么办？
　　如果在申请动态内存时找不到足够大的内存块malloc和new将返回NULL指针，宣告内存申请失败通常有三种方式处理“内存耗尽”问题。

　　（1）判断指针是否为NULL如果是则马上用return语句终止本函数。例如：

　（2）判断指针是否为NULL如果是则马上用exit(1)终止整个程序的运行。例如：

　　（3）为new和malloc设置异常处理函数例如Visual C++可以用_set_new_hander函数为new设置用户自己定义的异常处理函数，也可鉯让malloc享用与new相同的异常处理函数详细内容请参考C++使用手册。

　　上述（1）（2）方式使用最普遍如果一个函数内有多处需要申请动态内存，那么方式（1）就显得力不从心（释放内存很麻烦）应该用方式（2）来处理。

　　很多人不忍心用exit(1)问：“不编写出错处理程序，让操作系统自己解决行不行”

　　不行。如果发生“内存耗尽”这样的事情一般说来应用程序已经无药可救。如果不用exit(1) 把坏程序杀死咜可能会害死操作系统。道理如同：如果不把歹徒击毙歹徒在老死之前会犯下更多的罪。

　　有一个很重要的现象要告诉大家对于32位鉯上的应用程序而言，无论怎样使用malloc与new几乎不可能导致“内存耗尽”。我在Windows 98下用Visual C++编写了测试程序见示例7。这个程序会无休止地运行下詓根本不会终止。因为32位操作系统支持“虚存”内存用完了，自动用硬盘空间顶替我只听到硬盘嘎吱嘎吱地响，Window 98已经累得对键盘、鼠标毫无反应

　　我可以得出这么一个结论：对于32位以上的应用程序，“内存耗尽”错误处理程序毫无用处这下可把Unix和Windows程序员们乐坏叻：反正错误处理程序不起作用，我就不写了省了很多麻烦。

我不想误导读者必须强调：不加错误处理将导致程序的质量很差，千万鈈可因小失大

用malloc申请一块长度为length的整数类型的内存，程序如下：

我们应当把注意力集中在两个要素上：“类型转换”和“sizeof”

* malloc返回值的類型是void *，所以在调用malloc时要显式地进行类型转换将void * 转换成所需要的指针类型。

* malloc函数本身并不识别要申请的内存是什么类型它只关心内存嘚总字节数。我们通常记不住int, float等数据类型的变量的确切字节数例如int变量在16位系统下是2个字节，在32位下是4个字节；而float变量在16位系统下是4个芓节在32位下也是4个字节。最好用以下程序作一次测试：

在malloc的“()”中使用sizeof运算符是良好的风格但要当心有时我们会昏了头，写出 p = malloc(sizeof(p))这样的程序来

函数free的原型如下：

为什么free函数不象malloc函数那样复杂呢？这是因为指针p的类型以及它所指的内存的容量事先都是知道的语句free(p)能正确哋释放内存。如果p是NULL指针那么free对p无论操作多少次都不会出问题。如果p不是NULL指针那么free对p连续操作两次就会导致程序运行错误。

这是因为new內置了sizeof、类型转换和类型安全检查功能对于非内部数据类型的对象而言，new在创建动态对象的同时完成了初始化工作如果对象有多个构慥函数，那么new的语句也可以有多种形式例如

如果用new创建对象数组，那么只能使用对象的无参数构造函数例如：

在用delete释放对象数组时，留意不要丢了符号‘[]’例如：

后者有可能引起程序崩溃和内存泄漏。

1.2 C++中的健壮指针和资源管理
　　我最喜欢的对资源的定义是："任何在伱的程序中获得并在此后释放的东西?quot;内存是一个相当明显的资源的例子它需要用new来获得，用delete来释放同时也有许多其它类型的资源文件呴柄、重要的片断、Windows中的GDI资源，等等将资源的概念推广到程序中创建、释放的所有对象也是十分方便的，无论对象是在堆中分配的还是茬栈中或者是在全局作用于内生命的

　　对于给定的资源的拥有着，是负责释放资源的一个对象或者是一段代码所有权分立为两种级別——自动的和显式的（automatic and explicit），如果一个对象的释放是由语言本身的机制来保证的这个对象的就是被自动地所有。例如一个嵌入在其他對象中的对象，他的清除需要其他对象来在清除的时候保证外面的对象被看作嵌入类的所有者。　　类似地每个在栈上创建的对象（莋为自动变量）的释放（破坏）是在控制流离开了对象被定义的作用域的时候保证的。这种情况下作用于被看作是对象的所有者。注意所有的自动所有权都是和语言的其他机制相容的包括异常。无论是如何退出作用域的——正常流程控制退出、一个break语句、一个return、一个goto、戓者是一个throw——自动资源都可以被清除

　　到目前为止，一切都很好！问题是在引入指针、句柄和抽象的时候产生的如果通过一个指針访问一个对象的话，比如对象在堆中分配C++不自动地关注它的释放。程序员必须明确的用适当的程序方法来释放这些资源比如说，如果一个对象是通过调用new来创建的它需要用delete来回收。一个文件是用CreateFile(Win32 API)打开的它需要用CloseHandle来关闭。用EnterCritialSection进入的临界区（Critical Section）需要LeaveCriticalSection退出等等。一个"裸"指针文件句柄，或者临界区状态没有所有者来确保它们的最终释放基本的资源管理的前提就是确保每个资源都有他们的所有者。

　　一个指针一个句柄，一个临界区状态只有在我们将它们封装入对象的时候才会拥有所有者这就是我们的第一规则：在构造函数中分配资源，在析构函数中释放资源

　　当你按照规则将所有资源封装的时候，你可以保证你的程序中没有任何的资源泄露这点在当封装對象（Encapsulating Object）在栈中建立或者嵌入在其他的对象中的时候非常明显。但是对那些动态申请的对象呢不要急！任何动态申请的东西都被看作一種资源，并且要按照上面提到的方法进行封装这一对象封装对象的链不得不在某个地方终止。它最终终止在最高级的所有者自动的或鍺是静态的。这些分别是对离开作用域或者程序时释放资源的保证

　　下面是资源封装的一个经典例子。在一个多线程的应用程序中線程之间共享对象的问题是通过用这样一个对象联系临界区来解决的。每一个需要访问共享资源的客户需要获得临界区例如，这可能是Win32丅临界区的实现方法

　　这里聪明的部分是我们确保每一个进入临界区的客户最后都可以离开。"进入"临界区的状态是一种资源并应当被封装。封装器通常被称作一个锁（lock）

　　锁一般的用法如下：

　　注意无论发生什么，临界区都会借助于语言的机制保证释放

　　還有一件需要记住的事情——每一种资源都需要被分别封装。这是因为资源分配是一个非常容易出错的操作是要资源是有限提供的。我們会假设一个失败的资源分配会导致一个异常——事实上这会经常的发生。所以如果你想试图用一个石头打两只鸟的话或者在一个构慥函数中申请两种形式的资源，你可能就会陷入麻烦只要想想在一种资源分配成功但另一种失败抛出异常时会发生什么。因为构造函数還没有全部完成析构函数不可能被调用，第一种资源就会发生泄露

这种情况可以非常简单的避免。无论何时你有一个需要两种以上资源的类时写两个小的封装器将它们嵌入你的类中。每一个嵌入的构造都可以保证删除即使包装类没有构造完成。

　　我们至今还没有討论最常见类型的资源——用操作符new分配此后用指针访问的一个对象。我们需要为每个对象分别定义一个封装类吗（事实上，C++标准模板库已经有了一个模板类叫做auto_ptr，其作用就是提供这种封装我们一会儿在回到auto_ptr。）让我们从一个极其简单、呆板但安全的东西开始看丅面的Smart Pointer模板类，它十分坚固甚至无法实现。

　　为什么要把SmartPointer的构造函数设计为protected呢如果我需要遵守第一条规则，那么我就必须这样做資源——在这里是class T的一个对象——必须在封装器的构造函数中分配。但是我不能只简单的调用new T因为我不知道T的构造函数的参数。因为茬原则上，每一个T都有一个不同的构造函数；我需要为他定义个另外一个封装器模板的用处会很大，为每一个新的类我可以通过继承SmartPointer萣义一个新的封装器，并且提供一个特定的构造函数

　　为每一个类提供一个Smart Pointer真的值得吗？说实话——不！他很有教学的价值但是一旦你学会如何遵循第一规则的话，你就可以放松规则并使用一些高级的技术这一技术是让SmartPointer的构造函数成为public，但是只是是用它来做资源转換（Resource Transfer）我的意思是用new操作符的结果直接作为SmartPointer的构造函数的参数像这样：

　　这个方法明显更需要自控性，不只是你而且包括你的程序尛组的每个成员。他们都必须发誓出了作资源转换外不把构造函数用在人以其他用途幸运的是，这条规矩很容易得以加强只需要在源攵件中查找所有的new即可。

　　到目前为止我们所讨论的一直是生命周期在一个单独的作用域内的资源。现在我们要解决一个困难的问题——如何在不同的作用域间安全的传递资源这一问题在当你处理容器的时候会变得十分明显。你可以动态的创建一串对象将它们存放臸一个容器中，然后将它们取出并且在最终安排它们。为了能够让这安全的工作——没有泄露——对象需要改变其所有者

　　这个问題的一个非常显而易见的解决方法是使用Smart Pointer，无论是在加入容器前还是还找到它们以后这是他如何运作的，你加入Release方法到Smart Pointer中：

　　注意在Release調用以后Smart Pointer就不再是对象的所有者了——它内部的指针指向空。现在调用了Release都必须是一个负责的人并且迅速隐藏返回的指针到新的所有鍺对象中。在我们的例子中容器调用了Release，比如这个Stack的例子：

　　同样的你也可以再你的代码中用加强Release的可靠性。

相应的Pop方法要做些什麼呢他应该释放了资源并祈祷调用它的是一个负责的人而且立即作一个资源传递它到一个Smart Pointer？这听起来并不好

　　资源管理在内容索引（Windows NT Server上的一部分，现在是Windows 2000）上工作并且，我对这十分满意然后我开始想……这一方法是在这样一个完整的系统中形成的，如果可以把它內建入语言的本身岂不是一件非常好我提出了强指针（Strong Pointer）和弱指针(Weak Pointer)。一个Strong Pointer会在许多地方和我们这个SmartPointer相似--它在超出它的作用域后会清除他所指向的对象资源传递会以强指针赋值的形式进行。也可以有Weak Pointer存在它们用来访问对象而不需要所有对象--比如可赋值的引用。

Pointer的引入语訁将会使垃圾回收成为历史

　　这里还有一个小问题--修改C++标准几乎和竞选美国总统一样容易。当我将我的注意告诉给Bjarne Stroutrup的时候他看我的眼神好像是我刚刚要向他借一千美元一样。

然后我突然想到一个念头我可以自己实现Strong Pointers。毕竟它们都很想Smart Pointers。给它们一个拷贝构造函数并偅载赋值操作符并不是一个大问题事实上，这正是标准库中的auto_ptr有的重要的是对这些操作给出一个资源转移的语法，但是这也不是很难

　　使这整个想法迅速成功的原因之一是我可以以值方式传递这种封装指针！我有了我的蛋糕，并且也可以吃了看这个Stack的新的实现：

　　Pop方法强制客户将其返回值赋给一个Strong Pointer,SmartPointer<Item>。任何试图将他对一个普通指针的赋值都会产生一个编译期错误因为类型不匹配。此外因为Pop以徝方式返回一个Strong

我马上意识到我已经在某些东西之上了。我开始用了新的方法重写原来的代码

我过去有一个老的算术操作分析器，是用咾的资源管理的技术写的分析器的作用是在分析树中生成节点，节点是动态分配的例如分析器的Expression方法生成一个表达式节点。我没有时間用Strong Pointer去重写这个分析器我令Expression、Term和Factor方法以传值的方式将Strong Pointer返回到Node中。看下面的Expression方法的实现：

　　最开始Term方法被调用。他传值返回一个指向Node嘚Strong Pointer并且立刻把它保存到我们自己的Strong Pointer,pNode中如果下一个符号不是加号或者减号，我们就简单的把这个SmartPointer以值返回这样就释放了Node的所有权。另外┅方面如果下一个符号是加号或者减号，我们创建一个新的SumMode并且立刻（直接传递）将它储存到MultiNode的一个Strong

　　只要是他们在被加号和减号分開的时候我们就不断的创建terms，我们将这些term转移到我们的MultiNode中同时MultiNode得到了所有权。最后我们将指向MultiNode的Strong Pointer向上映射为指向Mode的Strong Pointer，并且将他返回調用着

　　如果你的编译器支持新加入标准的成员模板（member template）的话，你可以为SmartPointer<T>定义一个新的构造函数用来从接受一个class U

　　这里的这个花招是模板在U不是T的子类的时候就不会编译成功（换句话说，只在U is-a T的时候才会编译）这是因为uptr的缘故。Release()方法返回一个指向U的指针并被赋徝为_p，一个指向T的指针所以如果U不是一个T的话，赋值会导致一个编译时刻错误

后来我意识到在STL中的auto_ptr模板，就是我的Strong Pointer在那时候还有许哆的实现差异（auto_ptr的Release方法并不将内部的指针清零--你的编译器的库很可能用的就是这种陈旧的实现），但是最后在标准被广泛接受之前都被解決了

　　目前为止，我们一直在讨论在C++程序中资源管理的方法宗旨是将资源封装到一些轻量级的类中，并由类负责它们的释放特别嘚是，所有用new操作符分配的资源都会被储存并传递进Strong Pointer（标准库中的auto_ptr）的内部

　　这里的关键词是传递（passing）。一个容器可以通过传值返回┅个Strong Pointer来安全的释放资源容器的客户只能够通过提供一个相应的Strong Pointer来保存这个资源。任何一个将结果赋给一个"裸"指针的做法都立即会被编译器发现

semantics吗？不是这样的！它们所指向的对象肯定没有被拷贝过事实上，传递过后源auto_ptr不在访问原有的对象，并且目标auto_ptr成为了对象的唯┅拥有者（但是往往auto_ptr的旧的实现即使在释放后仍然保持着对对象的所有权）自然而然的我们可以将这种新的行为称作Transfer Semantics。

　　这是因为它們确实改变了他们的源--剥夺了对资源的所有权

通过定义相应的拷贝构造函数和重载赋值操作符，你可以将Transfer Semantics加入到许多对象中例如，许哆Windows中的资源比如动态建立的菜单或者位图，可以用有Transfer Semantics的类来封装

　　标准库只在auto_ptr中支持资源管理。甚至连最简单的容器也不支持ownership semantics你鈳能想将auto_ptr和标准容器组合到一起可能会管用，但是并不是这样的例如，你可能会这样做但是会发现你不能够用标准的方法来进行索引。

　　这种建造不会编译成功；

　　另一方面这会导致一个从autoVect到auto_ptr的所有权转换：

　　我们没有选择，只能够构造我们自己的Strong Vector最小的接ロ应该如下：

　　你也许会发现一个非常防御性的设计态度。我决定不提供一个对vector的左值索引的访问取而代之，如果你想设定(set)一个值的話你必须用assign或者assign_direct方法。我的观点是资源管理不应该被忽视，同时也不应该在所有的地方滥用。在我的经验里一个strong vector经常被许多push_back方法充斥着。

　　grow方法申请了一个很大的auto_ptr<T>的数组将所有的东西从老的书组类转移出来，在其中交换并且删除原来的数组。

　　auto_vector的其他实现嘟是十分直接的因为所有资源管理的复杂度都在auto_ptr中。例如assign方法简单的利用了重载的赋值操作符来删除原有的对象并转移资源到新的对潒：

　　对auto_vector的索引访问是借助auto_ptr的get方法来实现的，get简单的返回一个内部指针

　　没有容器可以没有iterator。我们需要一个iterator让auto_vector看起来更像一个普通嘚指针向量特别是，当我们废弃iterator的时候我们需要的是一个指针而不是auto_ptr。我们不希望一个auto_vector的iterator在无意中进行资源转换

　　你也许会问我們是否要利用资源管理重新实现每一个标准的容器？幸运的是不;事实是strong vector解决了大部分所有权的需求。当你把你的对象都安全的放置到一個strong vector中你可以用所有其它的容器来重新安排（weak）pointer。

　　如果你严格遵照资源管理的条款你就不会再资源泄露或者两次删除的地方遇到麻煩。你也降低了访问野指针的几率同样的，遵循原有的规则用delete删除用new申请的德指针，不要两次删除一个指针你也不会遇到麻烦。但昰那个是更好的注意呢？

　　这两个方法有一个很大的不同点就是和寻找传统方法的bug相比，找到违反资源管理的规定要容易的多后鍺仅需要一个代码检测或者一个运行测试，而前者则在代码中隐藏得很深并需要很深的检查。

　　设想你要做一段传统的代码的内存泄露检查第一件事，你要做的就是grep所有在代码中出现的new你需要找出被分配空间地指针都作了什么。你需要确定导致删除这个指针的所有嘚执行路径你需要检查break语句，过程返回异常。原有的指针可能赋给另一个指针你对这个指针也要做相同的事。

　　相比之下对于┅段用资源管理技术实现的代码。你也用grep检查所有的new但是这次你只需要检查邻近的调用：

　　● 这是一个直接的Strong Pointer转换，还是我们在一个構造函数的函数体中

　　● 调用的返回知是否立即保存到对象中，构造函数中是否有可以产生异常的代码？

　　● 如果这样的话析构函数中时候有delete?

　　下一步你需要用grep查找所有的release方法，并实施相同的检查

　　不同点是需要检查、理解单个执行路径和只需要做一些本哋的检验。这难道不是提醒你非结构化的和结构化的程序设计的不同吗原理上，你可以认为你可以应付goto并且跟踪所有的可能分支。另┅方面你可以将你的怀疑本地化为一段代码。本地化在两种情况下都是关键所在

　　在资源管理中的错误模式也比较容易调试。最常見的bug是试图访问一个释放过的strong pointer这将导致一个错误，并且很容易跟踪

　　为每一个程序中的资源都找出或者指定一个所有者是一件很容噫的事情吗？答案是出乎意料的是！如果你发现了一些问题，这可能说明你的设计上存在问题还有另一种情况就是共享所有权是最好嘚甚至是唯一的选择。

　　共享的责任分配给被共享的对象和它的客户（client）一个共享资源必须为它的所有者保持一个引用计数。另一方媔所有者再释放资源的时候必须通报共享对象。最后一个释放资源的需要在最后负责free的工作

　　最简单的共享的实现是共享对象继承引用计数的类RefCounted：

　　按照资源管理，一个引用计数是一种资源如果你遵守它，你需要释放它当你意识到这一事实的时候，剩下的就变嘚简单了简单的遵循规则--再构造函数中获得引用计数，在析构函数中释放甚至有一个RefCounted的smart pointer等价物：

　　注意模板中的T不比成为RefCounted的后代，泹是它必须有IncRefCount和DecRefCount的方法当然，一个便于使用的RefPtr需要有一个重载的指针访问操作符在RefPtr中加入转换语义学（transfer semantics）是读者的工作。

　　链表是資源管理分析中的一个很有意思的例子如果你选择表成为链(link)的所有者的话，你会陷入实现递归的所有权每一个link都是它的继承者的所有鍺，并且相应的，余下的链表的所有者下面是用smart pointer实现的一个表单元：

　　最好的方法是，将连接控制封装到一个弄构进行资源转换的類中

　　对于双链表呢？安全的做法是指明一个方向如forward:

　　注意不要创建环形链表。

　　这给我们带来了另外一个有趣的问题--资源管悝可以处理环形的所有权吗它可以，用一个mark-and-sweep的算法这里是实现这种方法的一个例子：

　　注意我们需要用class T来实现方法IsBeingDeleted，就像从CyclPtr继承對特殊的所有权网络普通化是十分直接的。

　　将原有代码转换为资源管理代码

如果你是一个经验丰富的程序员你一定会知道找资源的bug昰一件浪费时间的痛苦的经历。我不必说服你和你的团队花费一点时间来熟悉资源管理是十分值得的你可以立即开始用这个方法，无论伱是在开始一个新项目或者是在一个项目的中期转换不必立即全部完成。下面是步骤

最先封装的是在过程中定义的临时指针。简单的將它们替换为auto_ptr并且删除相应的delete如果一个指针在过程中没有被删除而是被返回，用auto_ptr替换并在返回前调用release方法在你做第二次传递的时候，伱需要处理对release的调用注意，即使是在这点你的代码也可能更加"精力充沛"--你会移出代码中潜在的资源泄漏问题。

（3）下面是指向资源的裸指针确保它们被独立的封装到auto_ptr中，或者在构造函数中分配在析构函数中释放如果你有传递所有权的行为的话，需要调用release方法如果伱有容器所有对象，用Strong Pointers重新实现它们

（5）重复着一过程，直到最后所有new和release的调用都在构造函数或者资源转换的时候发生这样，你在你嘚代码中处理了资源泄漏的问题对其他资源进行相似的操作。

（6）你会发现资源管理清除了许多错误和异常处理带来的复杂性不仅仅伱的代码会变得精力充沛，它也会变得简单并容易维护

2.1 C++中动态内存分配引发问题的解决方案
假设我们要开发一个String类，它可以方便地处理芓符串数据我们可以在类中声明一个数组，考虑到有时候字符串极长我们可以把数组大小设为200，但一般的情况下又不需要这么多的空間这样是浪费了内存。对了我们可以使用new操作符，这样是十分灵活的但在类中就会出现许多意想不到的问题，本文就是针对这一现潒而写的现在，我们先来开发一个String类但它是一个不完善的类。的确我们要刻意地使它出现各种各样的问题，这样才好对症下药好叻，我们开始吧！

cout＜＜"这个字符串将被删除："＜＜str＜＜'"n';//为了方便观察结果特留此行代码。

　　请按任意键继续. . .

　　大家可以看到以上程序十分正确，而且也是十分有用的可是，我们不能被表面现象所迷惑！下面请大家用test_String.cpp文件替换test_right.cpp文件进行编译，看看结果有的编译器可能就是根本不能进行编译！

cout＜＜"下面分别输入三个范例："n";

cout＜＜"使用正确的函数："＜＜endl;

cout＜＜"使用错误的函数："＜＜endl;

cout＜＜"下面，程序结束析构函数将被调用。"＜＜endl;

　　下面分别输入三个范例：

　　这个字符串将被删除：第一个范例

　　这个字符串将被删除：第二个范例。

　　这个字符串将被删除：?=

　　下面程序结束，析构函数将被调用

　　这个字符串将被删除：第四个范例。

　　这个字符串将被删除：第三个范例

　　这个字符串将被删除：?=

　　这个字符串将被删除：x =

　　这个字符串将被删除：?=

　　这个字符串将被删除：

现在，请夶家自己试试运行结果或许会更加惨不忍睹呢！下面，我为大家一一分析原因

首先，大家要知道C＋＋类有以下这些极为重要的函数：

我们先来讲复制构造函数。什么是复制构造函数呢比如，我们可以写下这样的代码：String test1(test2);这是进行初始化我们知道，初始化对象要用构慥函数可这儿呢？按理说应该有声明为这样的构造函数：String(const String &);可是，我们并没有定义这个构造函数呀答案是，C＋＋提供了默认的复制构慥函数问题也就出在这儿。

（1）：什么时候会调用复制构造函数呢（以String类为例。）

　　在我们提供这样的代码：String test1(test2)时它会被调用；当函数的参数列表为按值传递，也就是没有用引用和指针作为类型时如：void show_String(const String)，它会被调用其实，还有一些情况但在这儿就不列举了。

（2）：它是什么样的函数

它的作用就是把两个类进行复制。拿String类为例C＋＋提供的默认复制构造函数是这样的：

在平时，这样并不会有任哬的问题出现但我们用了new操作符，涉及到了动态内存分配我们就不得不谈谈浅复制和深复制了。以上的函数就是实行的浅复制它只昰复制了指针，而并没有复制指针指向的数据可谓一点儿用也没有。打个比方吧！就像一个朋友让你把一个程序通过网络发给他而你夶大咧咧地把快捷方式发给了他，有什么用处呢我们来具体谈谈：

假如，A对象中存储了这样的字符串：“C＋＋”它的地址为2000。现在峩们把A对象赋给B对象：String B=A。现在A和B对象的str指针均指向2000地址。看似可以使用但如果B对象的析构函数被调用时，则地址2000处的字符串“C＋＋”巳经被从内存中抹去而A对象仍然指向地址2000。这时如果我们写下这样的代码：cout＜＜A＜＜endl;或是等待程序结束，A对象的析构函数被调用时A對象的数据能否显示出来呢？只会是乱码而且，程序还会这样做：连续对地址2000处使用两次delete操作符这样的后果是十分严重的！

本例中，囿这样的代码：

　　假设test1中str指向的地址为2000,而String中str指针同样指向地址2000我们删除了2000处的数据，而test1对象呢已经被破坏了。大家从运行结果上可鉯看到我们使用cout＜＜test1时，一点反应也没有而在test1的析构函数被调用时，显示是这样：“这个字符串将被删除：”

cout＜＜"使用错误的函数："＜＜endl;

cout＜＜test2＜＜endl;//这一段代码出现严重的错误！

show_String函数的参数列表void show_String(const String a)是按值传递的，所以我们相当于执行了这样的代码：String a=test2;函数执行完毕，由于苼存周期的缘故对象a被析构函数删除，我们马上就可以看到错误的显示结果了：这个字符串将被删除：?=当然，test2也被破坏了解决的办法很简单，当然是手工定义一个复制构造函数喽！人力可以胜天！

　　我们执行的是深复制这个函数的功能是这样的：假设对象A中的str指針指向地址2000，内容为“I am a C++ Boy!”我们执行代码String B=A时，我们先开辟出一块内存假设为3000。我们用strcpy函数将地址2000的内容拷贝到地址3000中再将对象B的str指针指向地址3000。这样就互不干扰了。

大家把这个函数加入程序中问题就解决了大半，但还没有完全解决问题在赋值函数上。我们的程序Φ有这样的段代码：

　　经过我前面的讲解大家应该也会对这段代码进行寻根摸底：凭什么可以这样做：String3=test4？？原因是C＋＋为了用户嘚方便，提供的这样的一个操作符重载函数：operator=所以，我们可以这样做大家应该猜得到，它同样是执行了浅复制出了同样的毛病。比洳执行了这段代码后，析构函数开始大展神威^_^由于这些变量是后进先出的，所以最后的String3变量先被删除：这个字符串将被删除：第四个范例很正常。最后删除到test4的时候，问题来了：这个字符串将被删除：?=原因我不用赘述了，只是这个赋值函数怎么写还有一点儿学問呢！大家请看：

平时，我们可以写这样的代码：x=y=z（均为整型变量。）而在类对象中我们同样要这样，因为这很方便而对象A=B=C就是A.operator=(B.operator=(c))。洏这个operator=函数的参数列表应该是：const String& a所以，大家不难推出要实现这样的功能，返回值也要是String&这样才能实现A＝B＝C。我们先来写写看：

是不昰这样就行了呢我们假如写出了这种代码：A=A，那么大家看看岂不是把A对象的数据给删除了吗？这样可谓引发一系列的错误所以，我們还要检查是否为自身赋值只比较两对象的数据是不行了，因为两个对象的数据很有可能相同我们应该比较地址。以下是完好的赋值函数：

把这些代码加入程序问题就完全解决，下面是运行结果：

　　下面分别输入三个范例：

　　这个字符串将被删除：第一个范例

　　　使用正确的函数：

　　　使用错误的函数：

　　这个字符串将被删除：第二个范例。

　　下面程序结束，析构函数将被调用

　　这个字符串将被删除：第四个范例。

　　这个字符串将被删除：第三个范例

　　这个字符串将被删除：第四个范例。

　　这个字符串將被删除：第三个范例

　　这个字符串将被删除：第二个范例。

　　这个字符串将被删除：第一个范例

2.2 如何对付内存泄漏？
写出那些鈈会导致任何内存泄漏的代码很明显，当你的代码中到处充满了new 操作、delete操作和指针运算的话你将会在某个地方搞晕了头，导致内存泄漏指针引用错误，以及诸如此类的问题这和你如何小心地对待内存分配工作其实完全没有关系：代码的复杂性最终总是会超过你能够付出的时间和努力。于是随后产生了一些成功的技巧它们依赖于将内存分配（allocations）与重新分配（deallocation）工作隐藏在易于管理的类型之后。标准嫆器（standard containers）是一个优秀的例子它们不是通过你而是自己为元素管理内存，从而避免了产生糟糕的结果想象一下，没有string和vector的帮助写出这個：

　　你有多少机会在第一次就得到正确的结果？你又怎么知道你没有导致内存泄漏呢

　　注意，没有出现显式的内存管理宏，造型溢出检查，显式的长度限制以及指针。通过使用函数对象和标准算法（standard algorithm）我可以避免使用指针——例如使用迭代子（iterator），不过对於一个这么小的程序来说有点小题大作了

　　这些技巧并不完美，要系统化地使用它们也并不总是那么容易但是，应用它们产生了惊囚的差异而且通过减少显式的内存分配与重新分配的次数，你甚至可以使余下的例子更加容易被跟踪早在1981年，我就指出通过将我必須显式地跟踪的对象的数量从几万个减少到几打，为了使程序正确运行而付出的努力从可怕的苦工变成了应付一些可管理的对象，甚至哽加简单了

　　如果你的程序还没有包含将显式内存管理减少到最小限度的库，那么要让你程序完成和正确运行的话最快的途径也许僦是先建立一个这样的库。

　　模板和标准库实现了容器、资源句柄以及诸如此类的东西更早的使用甚至在多年以前。异常的使用使之哽加完善

　　如果你实在不能将内存分配/重新分配的操作隐藏到你需要的对象中时，你可以使用资源句柄（resource handle）以将内存泄漏的可能性降至最低。这里有个例子：我需要通过一个函数在空闲内存中建立一个对象并返回它。这时候可能忘记释放这个对象毕竟，我们不能說仅仅关注当这个指针要被释放的时候，谁将负责去做使用资源句柄，这里用了标准库中的auto_ptr使需要为之负责的地方变得明确了。

　// *p產生了内存泄漏

　// *q被自动释放

　　在更一般的意义上考虑资源而不仅仅是内存。

如果在你的环境中不能系统地应用这些技巧（例如你必须使用别的地方的代码，或者你的程序的另一部分简直是原始人类（译注：原文是Neanderthals尼安德特人，旧石器时代广泛分布在欧洲的猿人）寫的如此等等），那么注意使用一个内存泄漏检测器作为开发过程的一部分或者插入一个垃圾收集器（garbage collector）。

2.3浅谈C/C++内存泄漏及其检测工具
　　对于一个c/c++程序员来说内存泄漏是一个常见的也是令人头疼的问题。已经有许多技术被研究出来以应对这个问题比如Smart Pointer，Garbage Collection等Smart Pointer技术仳较成熟，STL中已经包含支持Smart Pointer的class但是它的使用似乎并不广泛，而且它也不能解决所有的问题；Garbage Collection技术在Java中已经比较成熟但是在c/c++领域的发展並不顺畅，虽然很早就有人思考在C++中也加入GC的支持现实世界就是这样的，作为一个c/c++程序员内存泄漏是你心中永远的痛。不过好在现在囿许多工具能够帮助我们验证内存泄漏的存在找出发生问题的代码。

2.3.1 内存泄漏的定义
一般我们常说的内存泄漏是指堆内存的泄漏堆内存是指程序从堆中分配的，大小任意的（内存块的大小可以在程序运行期决定）使用完后必须显示释放的内存。应用程序一般使用mallocrealloc，new等函数从堆中分配到一块内存使用完后，程序必须负责相应的调用free或delete释放该内存块否则，这块内存就不能被再次使用我们就说这块內存泄漏了。以下这段小程序演示了堆内存发生泄漏的情形：

　　当函数GetStringFrom()返回零的时候指针p指向的内存就不会被释放。这是一种常见的發生内存泄漏的情形程序在入口处分配内存，在出口处释放内存但是c函数可以在任何地方退出，所以一旦有某个出口处没有释放应该釋放的内存就会发生内存泄漏。

　　广义的说内存泄漏不仅仅包含堆内存的泄漏，还包含系统资源的泄漏(resource leak)比如核心态HANDLE，GDI ObjectSOCKET， Interface等从根本上说这些由操作系统分配的对象也消耗内存，如果这些对象发生泄漏最终也会导致内存的泄漏而且，某些对象消耗的是核心态内存这些对象严重泄漏时会导致整个操作系统不稳定。所以相比之下系统资源的泄漏比堆内存的泄漏更为严重。

GDI Object的泄漏是一种常见的资源泄漏：

　　当函数Something()返回非零的时候程序在退出前没有把pOldBmp选回pDC中，这会导致pOldBmp指向的HBITMAP对象发生泄漏这个程序如果长时间的运行，可能会导致整个系统花屏这种问题在Win9x下比较容易暴露出来，因为Win9x的GDI堆比Win2k或NT的要小很多

2.3.2 内存泄漏的发生方式
　　以发生的方式来分类，内存泄漏鈳以分为4类：

　　1. 常发性内存泄漏发生内存泄漏的代码会被多次执行到，每次被执行的时候都会导致一块内存泄漏比如例二，如果Something()函數一直返回True那么pOldBmp指向的HBITMAP对象总是发生泄漏。

　　2. 偶发性内存泄漏发生内存泄漏的代码只有在某些特定环境或操作过程下才会发生。比洳例二如果Something()函数只有在特定环境下才返回True，那么pOldBmp指向的HBITMAP对象并不总是发生泄漏常发性和偶发性是相对的。对于特定的环境偶发性的吔许就变成了常发性的。所以测试环境和测试方法对检测内存泄漏至关重要

3. 一次性内存泄漏。发生内存泄漏的代码只会被执行一次或鍺由于算法上的缺陷，导致总会有一块仅且一块内存发生泄漏比如，在类的构造函数中分配内存在析构函数中却没有释放该内存，但昰因为这个类是一个Singleton所以内存泄漏只会发生一次。另一个例子：

　　如果程序在结束的时候没有释放g_lpszFileName指向的字符串那么，即使多次调鼡SetFileName()总会有一块内存，而且仅有一块内存发生泄漏

4. 隐式内存泄漏。程序在运行过程中不停的分配内存但是直到结束的时候才释放内存。严格的说这里并没有发生内存泄漏因为最终程序释放了所有申请的内存。但是对于一个服务器程序需要运行几天，几周甚至几个月不及时释放内存也可能导致最终耗尽系统的所有内存。所以我们称这类内存泄漏为隐式内存泄漏。举一个例子：

　　假设在Client从Server端断开後Server并没有呼叫OnClientDisconnected()函数，那么代表那次连接的Connection对象就不会被及时的删除（在Server程序退出的时候所有Connection对象会在ConnectionManager的析构函数里被删除）。当不断嘚有连接建立、断开时隐式内存泄漏就发生了

从用户使用程序的角度来看，内存泄漏本身不会产生什么危害作为一般的用户，根本感覺不到内存泄漏的存在真正有危害的是内存泄漏的堆积，这会最终消耗尽系统所有的内存从这个角度来说，一次性内存泄漏并没有什麼危害因为它不会堆积，而隐式内存泄漏危害性则非常大因为较之于常发性和偶发性内存泄漏它更难被检测到。

　　检测内存泄漏的關键是要能截获住对分配内存和释放内存的函数的调用截获住这两个函数，我们就能跟踪每一块内存的生命周期比如，每当成功的分配一块内存后就把它的指针加入一个全局的list中；每当释放一块内存，再把它的指针从list中删除这样，当程序结束的时候list中剩余的指针僦是指向那些没有被释放的内存。这里只是简单的描述了检测内存泄漏的基本原理详细的算法可以参见Steve

　　如果要检测堆内存的泄漏，那么需要截获住malloc/realloc/free和new/delete就可以了（其实new/delete最终也是用malloc/free的所以只要截获前面一组即可）。对于其他的泄漏可以采用类似的方法，截获住相应的汾配和释放函数比如，要检测BSTR的泄漏就需要截获SysAllocString/SysFreeString；要检测HMENU的泄漏，就需要截获CreateMenu/ DestroyMenu（有的资源的分配函数有多个，释放函数只有一个仳如，SysAllocStringLen也可以用来分配BSTR这时就需要截获多个分配函数）

Monitor虽然无法标示出发生问题的代码，但是它能检测出隐式的内存泄漏的存在这是其他两类工具无能为力的地方。

　　以下我们详细讨论这三种检测工具：

　　用MFC开发的应用程序在DEBUG版模式下编译后，都会自动加入内存泄漏的检测代码在程序结束后，如果发生了内存泄漏在Debug窗口中会显示出所有发生泄漏的内存块的信息，以下两行显示了一块被泄漏的內存块的信息：

　　第一行显示该内存块由TestDlg.cpp文件第70行代码分配，地址在0x大小为200字节，{59}是指调用内存分配函数的Request Order关于它的详细信息可鉯参见MSDN中_CrtSetBreakAlloc()的帮助。第二行显示该内存块前16个字节的内容尖括号内是以ASCII方式显示，接着的是以16进制方式显示

注意观察一下由MFC Application Wizard生成的项目，在每一个cpp文件的头部都有这样一段宏定义：

有了这样的定义在编译DEBUG版时，出现在这个cpp文件中的所有new都被替换成DEBUG_NEW了那么DEBUG_NEW是什么呢？DEBUG_NEW也昰一个宏以下摘自afx.h，1632行

所以如果有这样一行代码：

根据C++的标准对于以上的new的使用方法，编译器会去找这样定义的operator new：

　　第二个operator new函数比較长为了简单期间，我只摘录了部分很显然最后的内存分配还是通过_malloc_dbg函数实现的，这个函数属于MS C-Runtime Library 的Debug Function这个函数不但要求传入内存的大尛，另外还有文件名和行号两个参数文件名和行号就是用来记录此次分配是由哪一段代码造成的。如果这块内存在程序结束之前没有被釋放那么这些信息就会输出到Debug窗口里。

　　这里顺便提一下THIS_FILE__FILE和__LINE__。__FILE__和__LINE__都是编译器定义的宏当碰到__FILE__时，编译器会把__FILE__替换成一个字符串這个字符串就是当前在编译的文件的路径名。当碰到__LINE__时编译器会把__LINE__替换成一个数字，这个数字就是当前这行代码的行号在DEBUG_NEW的定义中没囿直接使用__FILE__，而是用了THIS_FILE其目的是为了减小目标文件的大小。假设在某个cpp文件中有100处使用了new如果直接使用__FILE__，那编译器会产生100个常量字符串这100个字符串都是飧?/SPAN>cpp文件的路径名，显然十分冗余如果使用THIS_FILE，编译器只会产生一个常量字符串那100处new的调用使用的都是指向常量字符串的指针。

　　再次观察一下由MFC Application Wizard生成的项目我们会发现在cpp文件中只对new做了映射，如果你在程序中直接使用malloc函数分配内存调用malloc的文件名囷行号是不会被记录下来的。如果这块内存发生了泄漏MS C-Runtime Library仍然能检测到，但是当输出这块内存块的信息不会包含分配它的的文件名和行號。

要在非MFC程序中打开内存泄漏的检测功能非常容易你只要在程序的入口处加入以下几行代码：

　　这样，在程序结束的时候也就是winmain，main或dllmain函数返回之后如果还有内存块没有释放，它们的信息会被打印到Debug窗口里

如果你试着创建了一个非MFC应用程序，而且在程序的入口处加入了以上代码并且故意在程序中不释放某些内存块，你会在Debug窗口里看到以下的信息：

　　内存泄漏的确检测到了但是和上面MFC程序的唎子相比，缺少了文件名和行号对于一个比较大的程序，没有这些信息解决问题将变得十分困难。

　　为了能够知道泄漏的内存块是茬哪里分配的你需要实现类似MFC的映射功能，把newmaolloc等函数映射到_malloc_dbg函数上。这里我不再赘述你可以参考MFC的源代码。

Library分配的内存比如VARIANT，BSTR的泄漏它是无法检测到的，这是这种检测法的一个重大的局限性另外，为了能记录内存块是在哪里分配的源代码必须相应的配合，这茬调试一些老的程序非常麻烦毕竟修改源代码不是一件省心的事，这是这种检测法的另一个局限性

对于开发一个大型的程序，MS C-Runtime Library提供的檢测功能是远远不够的接下来我们就看看外挂式的检测工具。我用的比较多的是BoundsChecker一则因为它的功能比较全面，更重要的是它的稳定性这类工具如果不稳定，反而会忙里添乱到底是出自鼎鼎大名的NuMega，我用下来基本上没有什么大问题

Injection的技术，来截获对分配内存和释放內存的函数的调用简单地说，当你的程序开始运行时BoundsChecker的DLL被自动载入进程的地址空间（这可以通过system-level的Hook实现），然后它会修改进程中对内存分配和释放的函数调用让这些调用首先转入它的代码，然后再执行原来的代码BoundsChecker在做这些动作的时，无须修改被调试程序的源代码或笁程配置文件这使得使用它非常的简便、直接。

　　这里我们以malloc函数为例截获其他的函数方法与此类似。

　　需要被截获的函数可能茬DLL中也可能在程序的代码里。比如如果静态连结C-Runtime Library，那么malloc函数的代码会被连结到程序里为了截获住对这类函数的调用，BoundsChecker会动态修改这些函数的指令

　　当BoundsChecker介入后，函数malloc的前三条汇编指令被替换成一条jmp指令原来的三条指令被搬到地址01F41EC8处了。当程序进入malloc后先jmp到01F41EC8执行原來的三条指令，然后就是BoundsChecker的天下了大致上它会先记录函数的返回地址（函数的返回地址在stack上，所以很容易修改）然后把返回地址指向屬于BoundsChecker的代码，接着跳到malloc函数原来的指令也就是在00403c15的地方。当malloc函数结束的时候由于返回地址被修改，它会返回到BoundsChecker的代码中此时BoundsChecker会记录甴malloc分配的内存的指针，然后再跳转到到原来的返回地址去

　　如果内存分配/释放函数在DLL中，BoundsChecker则采用另一种方法来截获对这些函数的调用BoundsChecker通过修改程序的DLL Import Table让table中的函数地址指向自己的地址，以达到截获的目的

截获住这些分配和释放函数，BoundsChecker就能记录被分配的内存或资源的生命周期接下来的问题是如何与源代码相关，也就是说当BoundsChecker检测到内存泄漏它如何报告这块内存块是哪段代码分配的。答案是调试信息（Debug Information）当我们编译一个Debug版的程序时，编译器会把源代码和二进制代码之间的对应关系记录下来放到一个单独的文件里(.pdb)或者直接连结进目标程序，通过直接读取调试信息就能得到分配某块内存的源代码在哪个文件哪一行上。使用Code Injection和Debug Information使BoundsChecker不但能记录呼叫分配函数的源代码的位置，而且还能记录分配时的Call Stack以及Call Stack上的函数的源代码位置。这在使用像MFC这样的类库时非常有用以下我用一个例子来说明：

　　这里省略叻其他的函数调用

　　如此，我们很容易找到发生问题的函数是ShowYItemMenu()当使用MFC之类的类库编程时，大部分的API调用都被封装在类库的class里有了Call Stack信息，我们就可以非常容易的追踪到真正发生泄漏的代码

　　记录Call Stack信息会使程序的运行变得非常慢，因此默认情况下BoundsChecker不会记录Call Stack信息可以按照以下的步骤打开记录Call Stack信息的选项开关：

　　基于Code Injection，BoundsChecker还提供了API Parameter的校验功能memory over run等功能。这些功能对于程序的开发都非常有益由于这些内嫆不属于本文的主题，所以不在此详述了

尽管BoundsChecker的功能如此强大，但是面对隐式内存泄漏仍然显得苍白无力所以接下来我们看看如何用Performance Monitor檢测内存泄漏。

　　NT的内核在设计过程中已经加入了系统监视功能比如CPU的使用率，内存的使用情况I/O操作的频繁度等都作为一个个Counter，应鼡程序可以通过读取这些Counter了解整个系统的或者某个进程的运行状况Performance Monitor就是这样一个应用程序。

Bytes记录了该进程当前在虚地址空间上使用的虚擬内存的大小NT的内存分配采用了两步走的方法，首先在虚地址空间上保留一段空间，这时操作系统并没有分配物理内存只是保留了┅段地址。然后再提交这段空间，这时操作系统才会分配物理内存所以，Virtual Bytes一般总大于程序的Working Set监视Virutal Bytes可以帮助我们发现一些系统底层的問题; Working Set记录了操作系统为进程已提交的内存的总量，这个值和程序申请的内存总量存在密切的关系如果程序存在内存的泄漏这个值会持续增加，但是Virtual Bytes却是跳跃式增加的

　　监视这些Counter可以让我们了解进程使用内存的情况，如果发生了泄漏即使是隐式内存泄漏，这些Counter的值也會持续增加但是，我们知道有问题却不知道哪里有问题所以一般使用Performance Monitor来验证是否有内存泄漏，而使用BoundsChecker来找到和解决

　　当Performance Monitor显示有内存泄漏，而BoundsChecker却无法检测到这时有两种可能：第一种，发生了偶发性内存泄漏这时你要确保使用Performance Monitor和使用BoundsChecker时，程序的运行环境和操作方法昰一致的第二种，发生了隐式的内存泄漏这时你要重新审查程序的设计，然后仔细研究Performance Monitor记录的Counter的值的变化图分析其中的变化和程序運行逻辑的关系，找到一些可能的原因这是一个痛苦的过程，充满了假设、猜想、验证、失败但这也是一个积累经验的绝好机会。

3 探討C++内存回收
　　如果一个人自称为程序高手却对内存一无所知，那么我可以告诉你他一定在吹牛。用C或C++写程序需要更多地关注内存，这不仅仅是因为内存的分配是否合理直接影响着程序的效率和性能更为主要的是，当我们操作内存的时候一不小心就会出现问题而苴很多时候，这些问题都是不易发觉的比如内存泄漏，比如悬挂指针笔者今天在这里并不是要讨论如何避免这些问题，而是想从另外┅个角度来认识C++内存对象

　　我们知道，C++将内存划分为三个逻辑区域：堆、栈和静态存储区既然如此，我称位于它们之中的对象分别為堆对象栈对象以及静态对象。那么这些不同的内存对象有什么区别了堆对象和栈对象各有什么优劣了？如何禁止创建堆对象或栈对潒了这些便是今天的主题。

　　先来看看栈栈，一般用于存放局部变量或对象如我们在函数定义中用类似下面语句声明的对象：

　　stack_object便是一个栈对象，它的生命期是从定义点开始当所在函数返回时，生命结束

　　另外，几乎所有的临时对象都是栈对象比如，下媔的函数定义：

　　这个函数至少产生两个临时对象首先，参数是按值传递的所以会调用拷贝构造函数生成一个临时对象object_copy1 ，在函数内蔀使用的不是使用的不是object而是object_copy1，自然object_copy1是一个栈对象，它在函数返回时被释放；还有这个函数是值返回的在函数返回时，如果我们不栲虑返回值优化（NRV）那么也会产生一个临时对象object_copy2，这个临时对象会在函数返回后一段时间内被释放比如某个函数中有如下代码：

　　仩面的第二个语句的执行情况是这样的，首先函数fun返回时生成一个临时对象object_copy2 然后再调用赋值运算符执行

　　看到了吗？编译器在我们毫無知觉的情况下为我们生成了这么多临时对象，而生成这些临时对象的时间和空间的开销可能是很大的所以，你也许明白了为什么對于“大”对象最好用const引用传递代替按值进行函数参数传递了。

　　接下来看看堆。堆又叫自由存储区，它是在程序执行的过程中动態分配的所以它最大的特性就是动态性。在C++中所有堆对象的创建和销毁都要由程序员负责，所以如果处理不好，就会发生内存问题如果分配了堆对象，却忘记了释放就会产生内存泄漏；而如果已释放了对象，却没有将相应的指针置为NULL该指针就是所谓的“悬挂指針”，再度使用此指针时就会出现非法访问，严重时就导致程序崩溃

　　那么，C++中是怎样分配堆对象的唯一的方法就是用new（当然，鼡类malloc指令也可获得C式堆内存）只要使用new，就会在堆中分配一块内存并且返回指向该堆对象的指针。

　　再来看看静态存储区所有的靜态对象、全局对象都于静态存储区分配。关于全局对象是在main()函数执行前就分配好了的。其实在main()函数中的显示代码执行之前，会调用┅个由编译器生成的_main()函数而_main()函数会进行所有全局对象的的构造及初始化工作。而在main()函数结束之前会调用由编译器生成的exit函数，来释放所有的全局对象比如下面的代码：

　… …// 显式代码

　　实际上，被转化成这样：

　_main（）; //隐式代码由编译器产生，用以构造所有全局对潒

　… … // 显式代码

　exit（） ; // 隐式代码由编译器产生，用以释放所有全局对象

　　所以知道了这个之后，便可以由此引出一些技巧如，假设我们要在main()函数执行之前做某些准备工作那么我们可以将这些准备工作写到一个自定义的全局对象的构造函数中，这样在main()函数的显式代码执行之前，这个全局对象的构造函数会被调用执行预期的动作，这样就达到了我们的目的刚才讲的是静态存储区中的全局对象，那么局部静态对象了？局部静态对象通常也是在函数中定义的就像栈对象一样，只不过其前面多了个static关键字。局部静态对象的生命期是从其所在函数第一次被调用更确切地说，是当第一次执行到该静态对象的声明代码时产生该静态局部对象，直到整个程序结束時才销毁该对象。

　　还有一种静态对象那就是它作为class的静态成员。考虑这种情况时就牵涉了一些较复杂的问题。

　　第一个问题昰class的静态成员对象的生命期class的静态成员对象随着第一个class object的产生而产生，在整个程序结束时消亡也就是有这样的情况存在，在程序中我們定义了一个class该类中有一个静态对象作为成员，但是在程序执行过程中如果我们没有创建任何一个该class object，那么也就不会产生该class所包含的那个静态对象还有，如果创建了多个class object那么所有这些object都共享那个静态对象成员。

　　第二个问题是当出现下列情况时：

　　请注意上媔标为黑体的三条语句，它们所访问的s_object是同一个对象吗答案是肯定的，它们的确是指向同一个对象这听起来不像是真的，是吗但这昰事实，你可以自己写段简单的代码验证一下我要做的是来解释为什么会这样？我们知道当一个类比如Derived1，从另一个类比如Base继承时那麼，可以看作一个Derived1对象中含有一个Base型的对象这就是一个subobject。一个Derived1对象的大致内存布局如下：

　　让我们想想当我们将一个Derived1型的对象传给┅个接受非引用Base型参数的函数时会发生切割，那么是怎么切割的呢相信现在你已经知道了，那就是仅仅取出了Derived1型的对象中的subobject而忽略了所有Derived1自定义的其它数据成员，然后将这个subobject传递给函数（实际上函数中使用的是这个subobject的拷贝）。

　　所有继承Base类的派生类的对象都含有一個Base型的subobject（这是能用Base型指针指向一个Derived1对象的关键所在自然也是多态的关键了），而所有的subobject和所有Base型的对象都共用同一个s_object对象自然，从Base类派生的整个继承体系中的类的实例都会共用同一个s_object对象了上面提到的example、example1、example2的对象布局如下图所示：

3.1.2 三种内存对象的比较
　　栈对象的优勢是在适当的时候自动生成，又在适当的时候自动销毁不需要程序员操心；而且栈对象的创建速度一般较堆对象快，因为分配堆对象时会调用operator new操作，operator new会采用某种内存空间搜索算法而该搜索过程可能是很费时间的，产生栈对象则没有这么麻烦它仅仅需要移动栈顶指针僦可以了。但是要注意的是通常栈空间容量比较小，一般是1MB～2MB所以体积比较大的对象不适合在栈中分配。特别要注意递归函数中最好鈈要使用栈对象因为随着递归调用深度的增加，所需的栈空间也会线性增加当所需栈空间不够时，便会导致栈溢出这样就会产生运荇时错误。

　　堆对象其产生时刻和销毁时刻都要程序员精确定义，也就是说程序员对堆对象的生命具有完全的控制权。我们常常需偠这样的对象比如，我们需要创建一个对象能够被多个函数所访问，但是又不想使其成为全局的那么这个时候创建一个堆对象无疑昰良好的选择，然后在各个函数之间传递这个堆对象的指针便可以实现对该对象的共享。另外相比于栈空间，堆的容量要大得多实際上，当物理内存不够时如果这时还需要生成新的堆对象，通常不会产生运行时错误而是系统会使用虚拟内存来扩展实际的物理内存。

接下来看看static对象

　　首先是全局对象。全局对象为类间通信和函数间通信提供了一种最简单的方式虽然这种方式并不优雅。一般而訁在完全的面向对象语言中，是不存在全局对象的比如C#，因为全局对象意味着不安全和高耦合在程序中过多地使用全局对象将大大降低程序的健壮性、稳定性、可维护性和可复用性。C++也完全可以剔除全局对象但是最终没有，我想原因之一是为了兼容C

　　其次是类嘚静态成员，上面已经提到基类及其派生类的所有对象都共享这个静态成员对象，所以当需要在这些class之间或这些class objects之间进行数据共享或通信时这样的静态成员无疑是很好的选择。

　　接着是静态局部对象主要可用于保存该对象所在函数被屡次调用期间的中间状态，其中┅个最显著的例子就是递归函数我们都知道递归函数是自己调用自己的函数，如果在递归函数中定义一个nonstatic局部对象那么当递归次数相當大时，所产生的开销也是巨大的这是因为nonstatic局部对象是栈对象，每递归调用一次就会产生一个这样的对象，每返回一次就会释放这個对象，而且这样的对象只局限于当前调用层，对于更深入的嵌套层和更浅露的外层都是不可见的。每个层都有自己的局部对象和参數

　　在递归函数设计中，可以使用static对象替代nonstatic局部对象（即栈对象）这不仅可以减少每次递归调用和返回时产生和释放nonstatic对象的开销，洏且static对象还可以保存递归调用的中间状态并且可为各个调用层所访问。

3.1.3 使用栈对象的意外收获
　　前面已经介绍到栈对象是在适当的時候创建，然后在适当的时候自动释放的也就是栈对象有自动管理功能。那么栈对象会在什么会自动释放了第一，在其生命期结束的時候；第二在其所在的函数发生异常的时候。你也许说这些都很正常啊，没什么大不了的是的，没什么大不了的但是只要我们再罙入一点点，也许就有意外的收获了

　　栈对象，自动释放时会调用它自己的析构函数。如果我们在栈对象中封装资源而且在栈对潒的析构函数中执行释放资源的动作，那么就会使资源泄漏的概率大大降低因为栈对象可以自动的释放资源，即使在所在函数发生异常嘚时候实际的过程是这样的：函数抛出异常时，会发生所谓的stack_unwinding（堆栈回滚）即堆栈会展开，由于是栈对象自然存在于栈中，所以在堆栈回滚的过程中栈对象的析构函数会被执行，从而释放其所封装的资源除非，除非在析构函数执行的过程中再次抛出异常――而这種可能性是很小的所以用栈对象封装资源是比较安全的。基于此认识我们就可以创建一个自己的句柄或代理来封装资源了。智能指针（auto_ptr）中就使用了这种技术在有这种需要的时候，我们就希望我们的资源封装类只能在栈中创建也就是要限制在堆中创建该资源封装类嘚实例。

3.1.4 禁止产生堆对象
　　上面已经提到你决定禁止产生某种类型的堆对象，这时你可以自己创建一个资源封装类该类对象只能在棧中产生，这样就能在异常的情况下自动释放封装的资源

　　那么怎样禁止产生堆对象了？我们已经知道产生堆对象的唯一方法是使鼡new操作，如果我们禁止使用new不就行了么再进一步，new操作执行时会调用operator new而operator new是可以重载的。方法有了就是使new operator 为private，为了对称最好将operator delete也重載为private。现在你也许又有疑问了,难道创建栈对象不需要调用new吗？是的不需要，因为创建栈对象不需要搜索内存而是直接调整堆栈指针，将对象压栈而operator new的主要任务是搜索合适的堆内存，为堆对象分配空间这在上面已经提到过了。好让我们看看下面的示例代码：

　　　//此处可以获得需要封装的资源，并让ptr指针指向该资源

　　NoHashObject现在就是一个禁止堆对象的类了如果你写下如下代码：

上面代码会产生编译期错误。好了现在你已经知道了如何设计一个禁止堆对象的类了，你也许和我一样有这样的疑问难道在类NoHashObject的定义不能改变的情况下，僦一定不能产生该类型的堆对象了吗不，还是有办法的我称之为“暴力破解法”。C++是如此地强大强大到你可以用它做你想做的任何倳情。这里主要用到的是技巧是指针类型的强制转换

　//强制类型转换，现在ptr是一个指向NoHashObject对象的指针

　//再一次强制类型转换让rp指针指向堆中NoHashObject对象的ptr成员

　　上面的实现是麻烦的，而且这种实现方式几乎不会在实践中使用但是我还是写出来路，因为理解它对于我们理解C++內存对象是有好处的。对于上面的这么多强制类型转换其最根本的是什么了？我们可以这样理解：

　　某块内存中的数据是不变的而類型就是我们戴上的眼镜，当我们戴上一种眼镜后我们就会用对应的类型来解释内存中的数据，这样不同的解释就得到了不同的信息

　　所谓强制类型转换实际上就是换上另一副眼镜后再来看同样的那块内存数据。

　　另外要提醒的是不同的编译器对对象的成员数据嘚布局安排可能是不一样的，比如大多数编译器将NoHashObject的ptr指针成员安排在对象空间的头4个字节，这样才会保证下面这条语句的转换动作像我們预期的那样执行：

　　但是并不一定所有的编译器都是如此。

　　既然我们可以禁止产生某种类型的堆对象那么可以设计一个类，使之不能产生栈对象吗当然可以。

3.1.5 禁止产生栈对象
　　前面已经提到了创建栈对象时会移动栈顶指针以“挪出”适当大小的空间，然後在这个空间上直接调用对应的构造函数以形成一个栈对象而当函数返回时，会调用其析构函数释放这个对象然后再调整栈顶指针收囙那块栈内存。在这个过程中是不需要operator new/delete操作的所以将operator new/delete设置为private不能达到目的。当然从上面的叙述中你也许已经想到了：将构造函数或析構函数设为私有的，这样系统就不能调用构造/析构函数了当然就不能在栈中生成对象了。

　　这样的确可以而且我也打算采用这种方案。但是在此之前有一点需要考虑清楚,那就是，如果我们将构造函数设置为私有那么我们也就不能用new来直接产生堆对象了，因为new在为對象分配空间后也会调用它的构造函数啊所以，我打算只将析构函数设置为private再进一步，将析构函数设为private除了会限制栈对象生成外还囿其它影响吗？是的这还会限制继承。

　　如果一个类不打算作为基类通常采用的方案就是将其析构函数声明为private。

　　为了限制栈对潒却不限制继承，我们可以将析构函数声明为protected这样就两全其美了。如下代码所示：

　　接着可以像这样使用NoStackObject类：

　　呵呵，是不是覺得有点怪怪的我们用new创建一个对象，却不是用delete去删除它而是要用destroy方法。很显然用户是不习惯这种怪异的使用方式的。所以我决萣将构造函数也设为private或}

奇偶密码网