我的文章 - c++,c,vc

博客首页注册建议与交流排行榜加入友情链接

推荐投诉搜索：帮助

c++,c,vc

ddwwoo.cublog.cn

关于作者

我的分类

文章列表 -

管理我的文章

数据结构C语言实现系列——队列

查看全文
发表于:2008-04-25 ┆ 阅读(48) ┆ 评论(0)

为C 标准库容器写自己的内存分配程序

查看全文
发表于:2008-04-25 ┆ 阅读(26) ┆ 评论(0)

高手详解：sscanf函数的高级用法

查看全文
发表于:2008-04-25 ┆ 阅读(71) ┆ 评论(0)

网友原创：自己对三层架构理论的理解

查看全文
发表于:2008-04-25 ┆ 阅读(55) ┆ 评论(0)

高手解答：关于RICHEDIT的两个问题

查看全文
发表于:2008-04-25 ┆ 阅读(42) ┆ 评论(0)

专家讲解用.NET编写串口程序的一点心得

查看全文
发表于:2008-04-25 ┆ 阅读(72) ┆ 评论(0)

高手讲解：探索C 的秘密之详解extern

<P>

<TBODY>

<TR>

<TD style="WORD-WRAP: break-word" bgColor=#f3f3f3><FONT style="FONT-WEIGHT: bold; COLOR: #990000">以下是引用片段：</FONT><BR>　　#ifdef __cplusplus <BR>　　extern "C" { <BR>　　#endif <BR>　　//一段代码 <BR>　　#ifdef __cplusplus <BR>　　} <BR>　　#endif</TD></TR></TBODY></TABLE></P>

<P>　　这样的代码到底是什么意思呢?首先，__cplusplus是cpp中的自定义宏，那么定义了这个宏的话表示这是一段cpp的代码，也就是说，上面的代码的含义是:如果这是一段cpp的代码，那么加入extern "C"{和}处理其中的代码。</P>

<P>　　要明白为何使用extern "C"，还得从cpp中对函数的重载处理开始说起。在c  中，为了支持重载机制，在编译生成的汇编码中，要对函数的名字进行一些处理，加入比如函数的返回类型等等.而在C中，只是简单的函数名字而已，不会加入其他的信息.也就是说:C  和C对产生的函数名字的处理是不一样的.</P>

<P>　　比如下面的一段简单的函数，我们看看加入和不加入extern "C"产生的汇编代码都有哪些变化:</P>

<P>

<TBODY>

<TR>

<TD style="WORD-WRAP: break-word" bgColor=#f3f3f3><FONT style="FONT-WEIGHT: bold; COLOR: #990000">以下是引用片段：</FONT><BR>　　int f(void) <BR>　　{ <BR>　　return 1; <BR>　　}</TD></TR></TBODY></TABLE></P>

<P>　　在加入extern "C"的时候产生的汇编代码是:</P>

<P>

<TBODY>

<TR>

<TD style="WORD-WRAP: break-word" bgColor=#f3f3f3><FONT style="FONT-WEIGHT: bold; COLOR: #990000">以下是引用片段：</FONT><BR>　　.file "test.cxx" <BR>　　.text <BR>　　.align 2 <BR>　　.globl _f <BR>　　.def _f; .scl 2; .type 32; .endef <BR>　　_f: <BR>　　pushl 雙 <BR>　　movl %esp， 雙 <BR>　　movl $1， 陎 <BR>　　popl 雙 <BR>　　ret</TD></TR></TBODY></TABLE></P>

<P>　　但是不加入了extern "C"之后</P>

<P>

<TBODY>

<TR>

<TD style="WORD-WRAP: break-word" bgColor=#f3f3f3><FONT style="FONT-WEIGHT: bold; COLOR: #990000">以下是引用片段：</FONT><BR>　　.file "test.cxx" <BR>　　.text <BR>　　.align 2 <BR>　　.globl __Z1fv <BR>　　.def __Z1fv; .scl 2; .type 32; .endef <BR>　　__Z1fv: <BR>　　pushl 雙 <BR>　　movl %esp， 雙 <BR>　　movl $1， 陎 <BR>　　popl 雙 <BR>　　ret</TD></TR></TBODY></TABLE></P>

<P>　　两段汇编代码同样都是使用gcc -S命令产生的，所有的地方都是一样的，唯独是产生的函数名，一个是_f，一个是__Z1fv。</P>

<P>　　明白了加入与不加入extern "C"之后对函数名称产生的影响，我们继续我们的讨论:为什么需要使用extern "C"呢?C  之父在设计C  之时，考虑到当时已经存在了大量的C代码，为了支持原来的C代码和已经写好C库，需要在C  中尽可能的支持C，而extern "C"就是其中的一个策略。</P>

<P>　　试想这样的情况:一个库文件已经用C写好了而且运行得很良好，这个时候我们需要使用这个库文件，但是我们需要使用C  来写这个新的代码。如果这个代码使用的是C  的方式链接这个C库文件的话，那么就会出现链接错误.我们来看一段代码:首先，我们使用C的处理方式来写一个函数，也就是说假设这个函数当时是用C写成的:</P>

<P>

<TBODY>

<TR>

<TD style="WORD-WRAP: break-word" bgColor=#f3f3f3><FONT style="FONT-WEIGHT: bold; COLOR: #990000">以下是引用片段：</FONT><BR>　　//f1.c <BR>　　extern "C" <BR>　　{ <BR>　　void f1() <BR>　　{ <BR>　　return; <BR>　　} <BR>　　}</TD></TR></TBODY></TABLE></P>

<P>　　编译命令是:gcc -c f1.c -o f1.o 产生了一个叫f1.o的库文件。再写一段代码调用这个f1函数:</P>

<P>

<TBODY>

<TR>

<TD style="WORD-WRAP: break-word" bgColor=#f3f3f3><FONT style="FONT-WEIGHT: bold; COLOR: #990000">以下是引用片段：</FONT><BR>　　// test.cxx <BR>　　//这个extern表示f1函数在别的地方定义，这样可以通过 <BR>　　//编译，但是链接的时候还是需要 <BR>　　//链接上原来的库文件. <BR>　　extern void f1(); <BR>　　int main() <BR>　　{ <BR>　　f1(); <BR>　　return 0; <BR>　　}</TD></TR></TBODY></TABLE></P>

<P>　　通过gcc -c test.cxx -o test.o 产生一个叫test.o的文件。然后，我们使用gcc test.o f1.o来链接两个文件，可是出错了，错误的提示是:</P>

<P>

<TBODY>

<TR>

<TD style="WORD-WRAP: break-word" bgColor=#f3f3f3><FONT style="FONT-WEIGHT: bold; COLOR: #990000">以下是引用片段：</FONT><BR>　　test.o(.text   0x1f):test.cxx: undefine reference to 'f1()'</TD></TR></TBODY></TABLE></P>

<P>　　也就是说，在编译test.cxx的时候编译器是使用C  的方式来处理f1()函数的，但是实际上链接的库文件却是用C的方式来处理函数的，所以就会出现链接过不去的错误:因为链接器找不到函数。</P>

<P>　　因此，为了在C  代码中调用用C写成的库文件，就需要用extern "C"来告诉编译器:这是一个用C写成的库文件，请用C的方式来链接它们。</P>

<P>　　比如，现在我们有了一个C库文件，它的头文件是f.h，产生的lib文件是f.lib，那么我们如果要在C  中使用这个库文件，我们需要这样写:</P>

<P>

<TBODY>

<TR>

<TD style="WORD-WRAP: break-word" bgColor=#f3f3f3><FONT style="FONT-WEIGHT: bold; COLOR: #990000">以下是引用片段：</FONT><BR>　　extern "C" <BR>　　{ <BR>　　#include "f.h" <BR>　　}</TD></TR></TBODY></TABLE></P>

<P>　　回到上面的问题，如果要改正链接错误，我们需要这样子改写test.cxx:</P>

<P>

<TBODY>

<TR>

<TD style="WORD-WRAP: break-word" bgColor=#f3f3f3><FONT style="FONT-WEIGHT: bold; COLOR: #990000">以下是引用片段：</FONT><BR>　　extern "C" <BR>　　{ <BR>　　extern void f1(); <BR>　　} <BR>　　int main() <BR>　　{ <BR>　　f1(); <BR>　　return 0; <BR>　　}</TD></TR></TBODY></TABLE></P>

<P>　　重新编译并且链接就可以过去了.</P>

<P>　　C和C  对函数的处理方式是不同的.extern "C"是使C  能够调用C写作的库文件的一个手段，如果要对编译器提示使用C的方式来处理函数的话，那么就要使用extern "C"来说明。</P><BR>  阅读关于 <FONT color=red>C  </FONT> <FONT color=red>extern</FONT> 的全部文章

<P>

<TBODY>

<TR>

<P>　　比如下面的一段简单的函数，我们看看加入和不加入extern "C"产生的汇编代码都有哪些变化:</P>

<P>

<TBODY>

<TR>

<P>　　在加入extern "C"的时候产生的汇编代码是:</P>

<P>

<TABLE style="BORDER-RIGHT: #cccccc 1px dotted; TABLE-LAYOUT: fixed; BORDER-TOP: #cccccc 1px dotted; BORDER-LEFT: #cccccc

查看全文
发表于:2008-04-25 ┆ 阅读(77) ┆ 评论(0)

教你轻松给流程增加权限控制程序

查看全文
发表于:2008-04-25 ┆ 阅读(51) ┆ 评论(0)

在不装AD的情况下管理SPS的访问群体

查看全文
发表于:2008-04-25 ┆ 阅读(40) ┆ 评论(0)

数学与程序一道游戏题目的快速解法

查看全文
发表于:2008-04-25 ┆ 阅读(53) ┆ 评论(0)

ASP.NET页面事件：顺序与回传详解

查看全文
发表于:2008-04-25 ┆ 阅读(26) ┆ 评论(0)

MFC中消息循环处理的几个函数之间的区别

查看全文
发表于:2008-04-25 ┆ 阅读(75) ┆ 评论(0)

C与C 中标准输入实现方式上的一点区别

查看全文
发表于:2008-04-25 ┆ 阅读(32) ┆ 评论(0)

病毒及流氓软件自我复制的简单实现(C#)

查看全文
发表于:2008-04-25 ┆ 阅读(73) ┆ 评论(0)

实例：用Visual C#制作新闻阅读器

查看全文
发表于:2008-04-25 ┆ 阅读(47) ┆ 评论(0)

关于C#代码实现ControlTemplate

查看全文
发表于:2008-04-25 ┆ 阅读(45) ┆ 评论(0)

ASP.NET中为GridView添加删除提示框

查看全文
发表于:2008-04-25 ┆ 阅读(116) ┆ 评论(0)

教你如何在Ｃ语言使用位运算实现循环移位

查看全文
发表于:2008-04-25 ┆ 阅读(104) ┆ 评论(0)

专家详解：复杂表达式的执行步骤

查看全文
发表于:2008-04-25 ┆ 阅读(38) ┆ 评论(0)

解释一个关于Hibernate lazy的问题

查看全文
发表于:2008-04-25 ┆ 阅读(83) ┆ 评论(0)

Java版本和C 版本简单Stack程序

查看全文
发表于:2008-04-25 ┆ 阅读(39) ┆ 评论(0)

使用c#捕获windows的关机事件

查看全文
发表于:2008-04-25 ┆ 阅读(67) ┆ 评论(0)

关于C#静态构造函数的几点说明

查看全文
发表于:2008-04-25 ┆ 阅读(53) ┆ 评论(0)

C程序实现汉字内码与GB码

查看全文
发表于:2008-04-25 ┆ 阅读(53) ┆ 评论(0)

Visual C 编译器常用选项设置

查看全文
发表于:2008-04-25 ┆ 阅读(37) ┆ 评论(0)

内存调试技巧：C 语言最大难点揭秘

查看全文
发表于:2008-04-25 ┆ 阅读(24) ┆ 评论(0)

C 词汇解析集锦编程开发人员必备

查看全文
发表于:2008-04-25 ┆ 阅读(44) ┆ 评论(0)

C 启蒙之C 中的类

<DIV>
一起学习
<script type="text/javascript">
</script>
<script type="text/javascript"
src="http://pagead2.googlesyndication.com/pagead/show_ads.js">
</script>
　　上篇文章：<FONT color=#0909f7>C  启蒙之控制结构</FONT><BR><BR>　　在解决我们的书店问题之前，我们需要理解的唯一的剩余问题是如何编写一个数据结构（data structure）来表示我们的事务数据。在C  中我们通过定义类（class）来定义自己的数据结构。类机制是C  中最重要的特性之一。实际上，C  设计的主要聚焦点是使我们能够定义类类型（class types），使它的操作与内建类型一样自然。我们已经看到了类库类型（例如istream和ostream），它们都是作为类定义的--也就是说，严格地说，它们并不是语言的一部分。<BR><BR>　　完整地理解类机制需要掌握大量的信息。幸运的是，我们可以使用其他人编写的类而不需要知道自己如何定义类。在这一部分，我们将介绍一个简单的类，我们可以利用它来解决书店问题。<BR><BR>　　要使用某个类，我们必须知道三种信息：<BR><BR>　　1.它的名称是什么？<BR><BR>　　2.它是在哪儿定义的？<BR><BR>　　3.它支持哪些操作？<BR><BR>　　对于我们的书店问题，我们假设这个类叫做Sales_item，它是在一个叫做Sales_item.h的头文件中定义的。<BR><BR>　　<B>1、Sales_item类</B><BR><BR>　　Sales_item类的目的是存储一个ISBN并跟踪该书的销售数量、收入和平均售价。这些数据如何存储和计算是我们关心的问题。要使用一个类，我们不必知道它实现的细节信息。作为代替，我们只需要知道它所支持的操作。<BR><BR>　　我们已经看到，我们使用类似IO的类库工具的时候，我们必须包含相关的头文件。类似地，对于我们自己的类，我们也必须让编译器知道与类相关的定义。实现这样的功能的操作与前面的操作是相同的。典型情况下，我们把类定义放在一个文件中。任何希望使用我们的类的程序都必须包含这个文件。<BR><BR>　　按照惯例，类定义存储在一个文件中，与程序源文件的名字类似，它的名字有两个部分：文件名和扩展名。通常文件名与类的名字相同。扩展名通常是.h，但是有些程序员使用.H、.hpp或.hxx。编译器一般对头文件名称不太挑剔，但是有的IDE会挑剔的。我们假设自己的类定义在Sales_item.h文件中。<BR><BR>　　<B>Sales_item对象上的操作</B><BR><BR>　　每个类都定义了一个类型。这种类型的名称与类的名称相同。因此，我们的Sales_item类定义了Sales_item类型。与内建类型相似，我们可以定义类类型变量。当我们编写<BR><BR>

<TBODY>

<TR>

<TD>Sales_item item;</TD></TR></TBODY></TABLE><BR>　　我们就说是一个Sales_item类型的对象。我们通常约定"类型Sales_item的一个对象"等于"一个Sales_item对象"或简单地说"一个Sales_item"。<BR><BR>　　作为定义类型Sales_item的变量的补充，我们可以执行Sales_item对象上的如下一些操作：<BR><BR>　　· 使用加号操作符（ ）把两个Sales_item进行相加<BR><BR>　　· 使用输入操作符（&lt;&lt;）读取Sales_item对象<BR><BR>　　· 使用输出操作符（&gt;&gt;）写入Sales_item对象<BR><BR>　　· 使用赋值操作符（=）把Sales_item对象赋给另外一个<BR><BR>　　· 调用same_isb函数检测是否两个Sales_item指向同一本书<BR><BR>　　读取和写入Sales_item<BR><BR>　　现在我们知道了该类提供的操作，我们可以编写一些简单的程序来使用这个类了。例如，下面的程序从标准输入中读取数据，使用这些数据来建立Sales_item对象，并把该Sales_item对象写回标准的输出中：<BR><BR>

<TBODY>

<TR>

<TD>#include &lt;iostream&gt;<BR>#include "Sales_item.h"<BR>int main()<BR>{<BR>Sales_item book;<BR>// 读取ISBN、销售数量和售价<BR>std::cin &gt;&gt; book;<BR>// 写入ISBN、销售数量、总收入和平均售价<BR>std::cout &lt;&lt; book &lt;&lt; std::endl;<BR>return 0;<BR>}</TD></TR></TBODY></TABLE><BR>　　如果这个程序的输入信息是：<BR><BR>0-201-70353-X 4 24.99<BR><BR>　　那么它的输出信息是：<BR><BR>0-201-70353-X 4 99.96 24.99<BR><BR>　　输入信息说明我们销售了四本书，每本$24.99，输出信息表明总共销售了四本，总共的收入是$99.96，平均售价是$24.99。<BR><BR>　　这个程序以两个#include指令开始，其中一个使用了新的形式。Iostream头文件是标准类库定义的；Sales_item头文件不是标准类库定义的。Sales_item是我们自己定义的类型。当我们使用自己的头文件的时候，需要使用引号（" "）包含头文件名称。<BR><BR>　　注意：<BR><BR>　　标准类库的头文件是使用尖括号（&lt; &gt;）包含的。非标准的头文件使用引号（" "）包含。<BR><BR>　　在main中我们先定义了一个对象，叫做book，我们将使用它来保存那些从标准输入中读取的数据。下一个语句把输入读取该对象，第三个语句把它打印到标准的输出中，接着打印endl来刷新缓冲器。<BR><BR><div id="numpage">共2页。 1 2 <font face="Webdings">:</font>　　<B>类定义的行为</B><BR><BR>　　我们使用Sales_item的时候，要记住Sales_item类的作者定义了这个类的对象能够执行的全部操作。也就是说，Sales_item数据结构的作者定义了Sales_item对象建立的时候发生什么事情，在Sales_item对象上应用加、输入、输出等操作的时候发生什么情况，等等。一般来说，只有类所定义的操作才能在类类型的对象上使用。<BR><BR>　　<B>两个Sales_item相加</B><BR><BR>　　两个Sales_item对象相加的例子稍微有趣一些：<BR><BR>

<TBODY>

<TR>

<TD>#include &lt;iostream&gt;<BR>#include "Sales_item.h"<BR>int main()<BR>{<BR>Sales_item item1, item2;<BR>std::cin &gt;&gt; item1 &gt;&gt; item2; // 读取两个事务记录<BR>std::cout &lt;&lt; item1   item2 &lt;&lt; std::endl; // 输出它们的和<BR>return 0;<BR>}</TD></TR></TBODY></TABLE><BR>　　如果我们给这个程序输入下面的信息：<BR><BR>0-201-78345-X 3 20.00<BR>0-201-78345-X 2 25.00<BR><BR>　　输出结果是：<BR><BR>0-201-78345-X 5 110 22<BR><BR>　　这个程序先包含了Sales_item和iostream头文件。接着我们定义了两个Sales_item对象来保存我们希望汇总的两个事务。输出表达式执行加法操作并打印结果。我们知道两个Sales_item相加将建立一个新对象，它的ISBN为自己的操作数，售价和收入则反映了操作数中的相关值。我们还知道相加的项目必须有相同的ISBN。<BR><BR>　　上面的程序中有趣的地方是，我们不是读取并打印两个整数的和，而是读取并打印两个Sales_item对象的和。此外，求和的想法也是不同的。在使用整数的情况下我们生成传统的和--就是两个数值相加的结果。在使用Sales_item对象的时候，求和有新的意义--两个Sales_item对象相加的结果。<BR><BR>　　练习21：<BR><BR>　　Web站点包含了Sales_item.h的副本。把它复制到你的工作目录中。编写一个程序，在图书销售事务记录中进行循环，读取每个事务并把它写入标准的输出。<BR><BR>　　练习22：<BR><BR>　　编写一个程序，读取两个拥有相同的ISBN的Sales_item对象并生成它们的和。<BR><BR>　　练习23：<BR><BR>编写一个程序读取ISBN相同的几个事务记录，写出它们的和。<BR><BR>　　<B>2、初探成员函数</B><BR><BR>　　不幸的是，Sales_item相加的程序有个问题。如果你的输入信息使用了两个不同的ISBN会发生什么情况呢？它没有办法处理两个不同ISBN的数据相加。为了解决这个问题，我们将首先检查Sales_item操作数是否有相同的ISBN：<BR><BR>

<TBODY>

<TR>

<TD>#include &lt;iostream&gt;<BR>#include "Sales_item.h"<BR>int main()<BR>{<BR>Sales_item item1, item2;<BR>std::cin &gt;&gt; item1 &gt;&gt; item2;<BR>// 检查 item1 和 item2 是否是同一本书<BR>if (item1.same_isbn(item2)) {<BR>std::cout &lt;&lt; item1   item2 &lt;&lt; std::endl;<BR>return 0; //表示成功<BR>} else {<BR>std::cerr &lt;&lt; "Data must refer to same ISBN"<BR>&lt;&lt; std::endl;<BR>return -1; // indicate failure<BR>}<BR>}</TD></TR></TBODY></TABLE><BR>　　这个程序与前面的程序之间的区别在于if条件和相关的else分支。在解释if条件之前，我们知道程序的操作依赖于if中的条件。如果测试成功，那么我们写出与前面的程序相同的输出信息，并且返回0表明成功了。如果测试失败，我们执行else后面的代码块，它打印一条消息并返回错误标识符。<BR><BR>　　成员函数是什么？<BR><BR>　　If条件<BR><BR>

<TBODY>

<TR>

<TD>if (item1.same_isbn(item2)) {</TD></TR></TBODY></TABLE><BR>　　调用了Sales_item对象item1的成员函数。成员函数是类定义的函数。成员函数有时候也称为类的方法。<BR><BR>　　成员函数只在类中一次定义，但是每个对象都把它作为成员来处理。我们把这种操作称为成员函数是因为它们（通常）在特定的对象上操作。在例子中，它们都是对象的成员，即使单个定义也被相同类型的所有对象所共享。<BR><BR>　　当我们调用成员函数的时候，我们（通常）指定该函数在哪个对象上操作。其语法是使用点操作符（"."）：<BR><BR>

<TBODY>

<TR>

<TD>item1.same_isbn</TD></TR></TBODY></TABLE><BR>　　它的意思是"item1对象的same_isbn成员"。点操作符从它的左边取得右边的操作数。点操作符指定应用于类类型的对象：左边的操作数必须是类类型的对象；右边必须是该类型的成员的名称。<BR><BR>　　注意：<BR><BR>　　与大多数操作符不同，点操作符右边的操作数并不是对象或值；它是成员的名称。 <BR><BR>　　当我们把成员函数作为右边的操作数的时候，我们通常是调用这个函数。我们执行成员函数的方式与执行其它函数的方式相同：要调用函数，我们在函数名称后面加上调用操作符（"()"操作符）。调用操作符是一对括号，它封装了传递进该函数的参数列表（可能是空的）。<BR>same_isbn函数只有一个参数，这个参数是另一个Sales_item对象。下面的调用<BR><BR>

<TBODY>

<TR>

<TD>item1.same_isbn(item2)</TD></TR></TBODY></TABLE><BR>　　把item2作为参数传递进same_isbn函数，而这个函数是item1对象的一个成员。这个函数把参数item2中的ISBN部分与item1（调用same_isbn的对象）的ISBN进行比较。因此，其效果是测试两个对象的ISBN是否相同。<BR><BR>　　如果它们的ISBN相同，我们就执行if后面的语句，打印两个Sales_item对象相加的结果。否则，如果ISBN不同，我们将执行else分支，它也是一个代码块。这个代码块打印适当的错误信息并退出程序，返回-1。请回忆一下，main的返回值是被当作状态标识的。在例子中，返回非零的值表明程序生成预想的结果失败了。<div id="numpage">共2页。 <font face="Webdings">9</font> 1 2<script type="text/javascript">
</script>
<script type="text/javascript"
src="http://pagead2.googlesyndication.com/pagead/show_ads.js">
</script>　　上篇文章：<FONT color=#0909f7>C  启蒙之控制结构</FONT><BR><BR>　　在解决我们的书店问题之前，我们需要理解的唯一的剩余问题是如何编写一个数据结构（data structure）来表示我们的事务数据。在C  中我们通过定义类（class）来定义自己的数据结构。类机制是C  中最重要的特性之一。实际上，C  设计的主要聚焦点是使我们能够定义类类型（class types），使它的操作与内建类型一样自然。我们已经看到了类库类型（例如istream和ostream），它们都是作为类定义的--也就是说，严格地说，它们并不是语言的一部分。<BR><BR>　　完整地理解类机制需要掌握大量的信息。幸运的是，我们可以使用其他人编写的类而不需要知道自己如何定义类。在这一部分，我们将介绍一个简单的类，我们可以利用它来解决书店问题。<BR><BR>　　要使用某个类，我们必须知道三种信息：<BR><BR>　　1.它的名称是什么？<BR><BR>　　2.它是在哪儿定义的？<BR><BR>　　3.它支持哪些操作？<BR><BR>　　对于我们的书店问题，我们假设这个类叫做Sales_item，它是在一个叫做Sales_item.h的头文件中定义的。<BR><BR>　　<B>1、Sales_item类</B><BR><BR>　　Sales_item类的目的是存储一个ISBN并跟踪该书的销售数量、收入和平均售价。这些数据如何存储和计算是我们关心的问题。要使用一个类，我们不必知道它实现的细节信息。作为代替，我们只需要知道它所支持的操作。<BR><BR>　　我们已经看到，我们使用类似IO的类库工具的时候，我们必须包含相关的头文件。类似地，对于我们自己的类，我们也必须让编译器知道与类相关的定义。实现这样的功能的操作与前面的操作是相同的。典型情况下，我们把类定义放在一个文件中。任何希望使用我们的类的程序都必须包含这个文件。<BR><BR>　　按照惯例，类定义存储在一个文件中，与程序源文件的名字类似，它的名字有两个部分：文件名和扩展名。通常文件名与类的名字相同。扩展名通常是.h，但是有些程序员使用.H、.hpp或.hxx。编译器一般对头文件名称不太挑剔，但是有的IDE会挑剔的。我们假设自己的类定义在Sales_item.h文件中。<BR><BR>　　<B>Sales_item对象上的操作</B><BR><BR>　　每个类都定义了一个类型。这种类型的名称与类的名称相同。因此，我们的Sales_item类定义了Sales_item类型。与内建类型相似，我们可以定义类类型变量。当我们编写<BR><BR>

<TBODY>

<TR>

<TBODY>

<TR>

<TBODY>

<TR>

查看全文
发表于:2008-04-25 ┆ 阅读(39) ┆ 评论(0)

浅谈C/C 内存泄漏及其检测工具

<TBODY>

<TR>

<TD>void MyFunction(int nSize)<BR>{<BR>　char* p= new char[nSize];<BR>　if( !GetStringFrom( p, nSize ) ){<BR>　　MessageBox(“Error”);<BR>　　return;<BR>　}<BR>　…//using the string pointed by p;<BR>　delete p;<BR>}</TD></TR></TBODY></TABLE><BR>　　例一<BR><BR>　　当函数GetStringFrom()返回零的时候，指针p指向的内存就不会被释放。这是一种常见的发生内存泄漏的情形。程序在入口处分配内存，在出口处释放内存，但是c函数可以在任何地方退出，所以一旦有某个出口处没有释放应该释放的内存，就会发生内存泄漏。<BR><BR>　　广义的说，内存泄漏不仅仅包含堆内存的泄漏，还包含系统资源的泄漏(resource leak)，比如核心态HANDLE，GDI Object，SOCKET， Interface等，从根本上说这些由操作系统分配的对象也消耗内存，如果这些对象发生泄漏最终也会导致内存的泄漏。而且，某些对象消耗的是核心态内存，这些对象严重泄漏时会导致整个操作系统不稳定。所以相比之下，系统资源的泄漏比堆内存的泄漏更为严重。<BR><BR>　　GDI Object的泄漏是一种常见的资源泄漏：<BR><BR>

<TBODY>

<TR>

<TD>void CMyView::OnPaint( CDC* pDC )<BR>{<BR>　CBitmap bmp;<BR>　CBitmap* pOldBmp;<BR>　bmp.LoadBitmap(IDB_MYBMP);<BR>　pOldBmp = pDC-&gt;SelectObject( &amp;bmp );<BR>　…<BR>　if( Something() ){<BR>　　return;<BR>　}<BR>　pDC-&gt;SelectObject( pOldBmp );<BR>　return;<BR>}</TD></TR></TBODY></TABLE><BR>　　例二<BR><BR>　　当函数Something()返回非零的时候，程序在退出前没有把pOldBmp选回pDC中，这会导致pOldBmp指向的HBITMAP对象发生泄漏。这个程序如果长时间的运行，可能会导致整个系统花屏。这种问题在Win9x下比较容易暴露出来，因为Win9x的GDI堆比Win2k或NT的要小很多。<BR><BR>　　内存泄漏的发生方式：<BR><BR>　　以发生的方式来分类，内存泄漏可以分为4类：<BR><BR>　　1. 常发性内存泄漏。发生内存泄漏的代码会被多次执行到，每次被执行的时候都会导致一块内存泄漏。比如例二，如果Something()函数一直返回True，那么pOldBmp指向的HBITMAP对象总是发生泄漏。<BR><BR>　　2. 偶发性内存泄漏。发生内存泄漏的代码只有在某些特定环境或操作过程下才会发生。比如例二，如果Something()函数只有在特定环境下才返回True，那么pOldBmp指向的HBITMAP对象并不总是发生泄漏。常发性和偶发性是相对的。对于特定的环境，偶发性的也许就变成了常发性的。所以测试环境和测试方法对检测内存泄漏至关重要。<BR><BR>　　3. 一次性内存泄漏。发生内存泄漏的代码只会被执行一次，或者由于算法上的缺陷，导致总会有一块仅且一块内存发生泄漏。比如，在类的构造函数中分配内存，在析构函数中却没有释放该内存，但是因为这个类是一个Singleton，所以内存泄漏只会发生一次。另一个例子：<BR><BR>

<TBODY>

<TR>

<TD>char* g_lpszFileName = NULL;<BR><BR>void SetFileName( const char* lpcszFileName )<BR>{<BR>　if( g_lpszFileName ){<BR>　　free( g_lpszFileName );<BR>　}<BR>　g_lpszFileName = strdup( lpcszFileName );<BR>}</TD></TR></TBODY></TABLE><BR>　　例三<BR><BR>　　如果程序在结束的时候没有释放g_lpszFileName指向的字符串，那么，即使多次调用SetFileName()，总会有一块内存，而且仅有一块内存发生泄漏。<BR><BR>　　4. 隐式内存泄漏。程序在运行过程中不停的分配内存，但是直到结束的时候才释放内存。严格的说这里并没有发生内存泄漏，因为最终程序释放了所有申请的内存。但是对于一个服务器程序，需要运行几天，几周甚至几个月，不及时释放内存也可能导致最终耗尽系统的所有内存。所以，我们称这类内存泄漏为隐式内存泄漏。举一个例子： <BR><BR>

<TBODY>

<TR>

<TD>class Connection<BR>{<BR>　public:<BR>　　Connection( SOCKET s);<BR>　　~Connection();<BR>　　…<BR>　private:<BR>　　SOCKET _socket;<BR>　　…<BR>};<BR><BR>class ConnectionManager<BR>{<BR>　public:<BR>　　ConnectionManager(){}<BR>　　~ConnectionManager(){<BR>　　　list::iterator it;<BR>　　　for( it = _connlist.begin(); it != _connlist.end();   it ){<BR>　　　　delete （*it）;<BR>　　　}<BR>　　　_connlist.clear();<BR>　　}<BR>　　void OnClientConnected( SOCKET s ){<BR>　　　Connection* p = new Connection(s);<BR>　　　_connlist.push_back(p);<BR>　　}<BR>　　void OnClientDisconnected( Connection* pconn ){<BR>　　　_connlist.remove( pconn );<BR>　　　delete pconn;<BR>　　}<BR>　private:<BR>　　list _connlist;<BR>};</TD></TR></TBODY></TABLE><BR>　　例四<BR><BR>　　假设在Client从Server端断开后，Server并没有呼叫OnClientDisconnected()函数，那么代表那次连接的Connection对象就不会被及时的删除（在Server程序退出的时候，所有Connection对象会在ConnectionManager的析构函数里被删除）。当不断的有连接建立、断开时隐式内存泄漏就发生了。<BR><BR>　　从用户使用程序的角度来看，内存泄漏本身不会产生什么危害，作为一般的用户，根本感觉不到内存泄漏的存在。真正有危害的是内存泄漏的堆积，这会最终消耗尽系统所有的内存。从这个角度来说，一次性内存泄漏并没有什么危害，因为它不会堆积，而隐式内存泄漏危害性则非常大，因为较之于常发性和偶发性内存泄漏它更难被检测到。 <BR><BR><div id="numpage">共3页。 1 2 3 <font face="Webdings">:</font>　　<B>检测内存泄漏</B><BR><BR>　　检测内存泄漏的关键是要能截获住对分配内存和释放内存的函数的调用。截获住这两个函数，我们就能跟踪每一块内存的生命周期，比如，每当成功的分配一块内存后，就把它的指针加入一个全局的list中；每当释放一块内存，再把它的指针从list中删除。这样，当程序结束的时候，list中剩余的指针就是指向那些没有被释放的内存。这里只是简单的描述了检测内存泄漏的基本原理，详细的算法可以参见Steve Maguire的&lt;&lt;Writing Solid Code&gt;&gt;。<BR><BR>　　如果要检测堆内存的泄漏，那么需要截获住malloc/realloc/free和new/delete就可以了（其实new/delete最终也是用malloc/free的，所以只要截获前面一组即可）。对于其他的泄漏，可以采用类似的方法，截获住相应的分配和释放函数。比如，要检测BSTR的泄漏，就需要截获SysAllocString/SysFreeString；要检测HMENU的泄漏，就需要截获CreateMenu/ DestroyMenu。（有的资源的分配函数有多个，释放函数只有一个，比如，SysAllocStringLen也可以用来分配BSTR，这时就需要截获多个分配函数）<BR><BR>　　在Windows平台下，检测内存泄漏的工具常用的一般有三种，MS C-Runtime Library内建的检测功能；外挂式的检测工具，诸如，Purify，BoundsChecker等；利用Windows NT自带的Performance Monitor。这三种工具各有优缺点，MS C-Runtime Library虽然功能上较之外挂式的工具要弱，但是它是免费的；Performance Monitor虽然无法标示出发生问题的代码，但是它能检测出隐式的内存泄漏的存在，这是其他两类工具无能为力的地方。<BR><BR>　　以下我们详细讨论这三种检测工具：<BR><BR>　　VC下内存泄漏的检测方法<BR><BR>　　用MFC开发的应用程序，在DEBUG版模式下编译后，都会自动加入内存泄漏的检测代码。在程序结束后，如果发生了内存泄漏，在Debug窗口中会显示出所有发生泄漏的内存块的信息，以下两行显示了一块被泄漏的内存块的信息：<BR><BR>E:\TestMemLeak\TestDlg.cpp(70) : {59} normal block at 0x00881710, 200 bytes long.<BR><BR>Data: &lt;abcdefghijklmnop&gt; 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70<BR><BR>　　第一行显示该内存块由TestDlg.cpp文件，第70行代码分配，地址在0x00881710，大小为200字节，{59}是指调用内存分配函数的Request Order，关于它的详细信息可以参见MSDN中_CrtSetBreakAlloc()的帮助。第二行显示该内存块前16个字节的内容，尖括号内是以ASCII方式显示，接着的是以16进制方式显示。<BR><BR>　　一般大家都误以为这些内存泄漏的检测功能是由MFC提供的，其实不然。MFC只是封装和利用了MS C-Runtime Library的Debug Function。非MFC程序也可以利用MS C-Runtime Library的Debug Function加入内存泄漏的检测功能。MS C-Runtime Library在实现malloc/free，strdup等函数时已经内建了内存泄漏的检测功能。<BR><BR>　　注意观察一下由MFC Application Wizard生成的项目，在每一个cpp文件的头部都有这样一段宏定义：<BR><BR>

<TBODY>

<TR>

<TD>#ifdef _DEBUG<BR>#define new DEBUG_NEW<BR>#undef THIS_FILE<BR>static char THIS_FILE[] = __FILE__;<BR>#endif</TD></TR></TBODY></TABLE><BR>　　有了这样的定义，在编译DEBUG版时，出现在这个cpp文件中的所有new都被替换成DEBUG_NEW了。那么DEBUG_NEW是什么呢？DEBUG_NEW也是一个宏，以下摘自afx.h，1632行<BR><BR>

<TBODY>

<TR>

<TD>#define DEBUG_NEW new(THIS_FILE, __LINE__)</TD></TR></TBODY></TABLE><BR>　　所以如果有这样一行代码：<BR><BR>

<TBODY>

<TR>

<TD>char* p = new char[200];</TD></TR></TBODY></TABLE><BR>　　经过宏替换就变成了：<BR><BR>

<TBODY>

<TR>

<TD>char* p = new( THIS_FILE, __LINE__)char[200];</TD></TR></TBODY></TABLE><BR>　　根据C  的标准，对于以上的new的使用方法，编译器会去找这样定义的operator new：<BR><BR>

<TBODY>

<TR>

<TD>void* operator new(size_t, LPCSTR, int)</TD></TR></TBODY></TABLE><BR>　　我们在afxmem.cpp 63行找到了一个这样的operator new 的实现<BR><BR>

<TBODY>

<TR>

<TD>void* AFX_CDECL operator new(size_t nSize, LPCSTR lpszFileName, int nLine)<BR>{<BR>　return ::operator new(nSize, _NORMAL_BLOCK, lpszFileName, nLine);<BR>}<BR><BR>void* __cdecl operator new(size_t nSize, int nType, LPCSTR lpszFileName, int nLine)<BR>{<BR>　…<BR>　pResult = _malloc_dbg(nSize, nType, lpszFileName, nLine);<BR>　if (pResult != NULL)<BR>　　return pResult;<BR>　…<BR>}</TD></TR></TBODY></TABLE><BR>　　第二个operator new函数比较长，为了简单期间，我只摘录了部分。很显然最后的内存分配还是通过_malloc_dbg函数实现的，这个函数属于MS C-Runtime Library 的Debug Function。这个函数不但要求传入内存的大小，另外还有文件名和行号两个参数。文件名和行号就是用来记录此次分配是由哪一段代码造成的。如果这块内存在程序结束之前没有被释放，那么这些信息就会输出到Debug窗口里。<BR><BR>　　这里顺便提一下THIS_FILE，__FILE和__LINE__。__FILE__和__LINE__都是编译器定义的宏。当碰到__FILE__时，编译器会把__FILE__替换成一个字符串，这个字符串就是当前在编译的文件的路径名。当碰到__LINE__时，编译器会把__LINE__替换成一个数字，这个数字就是当前这行代码的行号。在DEBUG_NEW的定义中没有直接使用__FILE__，而是用了THIS_FILE，其目的是为了减小目标文件的大小。假设在某个cpp文件中有100处使用了new，如果直接使用__FILE__，那编译器会产生100个常量字符串，这100个字符串都是飧?/SPAN&gt;cpp文件的路径名，显然十分冗余。如果使用THIS_FILE，编译器只会产生一个常量字符串，那100处new的调用使用的都是指向常量字符串的指针。<BR><BR>　　再次观察一下由MFC Application Wizard生成的项目，我们会发现在cpp文件中只对new做了映射，如果你在程序中直接使用malloc函数分配内存，调用malloc的文件名和行号是不会被记录下来的。如果这块内存发生了泄漏，MS C-Runtime Library仍然能检测到，但是当输出这块内存块的信息，不会包含分配它的的文件名和行号。<BR><BR>　　要在非MFC程序中打开内存泄漏的检测功能非常容易，你只要在程序的入口处加入以下几行代码：<BR><BR>

<TBODY>

<TR>

<TD>int tmpFlag = _CrtSetDbgFlag( _CRTDBG_REPORT_FLAG );<BR><BR>tmpFlag |= _CRTDBG_LEAK_CHECK_DF;<BR><BR>_CrtSetDbgFlag( tmpFlag );</TD></TR></TBODY></TABLE><BR>　　这样，在程序结束的时候，也就是winmain，main或dllmain函数返回之后，如果还有内存块没有释放，它们的信息会被打印到Debug窗口里。<BR><BR>　　如果你试着创建了一个非MFC应用程序，而且在程序的入口处加入了以上代码，并且故意在程序中不释放某些内存块，你会在Debug窗口里看到以下的信息：<BR><BR>

<TBODY>

<TR>

<TD>{47} normal block at 0x00C91C90, 200 bytes long.<BR><BR>Data: &lt; &gt; 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F</TD></TR></TBODY></TABLE><BR>　　内存泄漏的确检测到了，但是和上面MFC程序的例子相比，缺少了文件名和行号。对于一个比较大的程序，没有这些信息，解决问题将变得十分困难。<BR><BR>　　为了能够知道泄漏的内存块是在哪里分配的，你需要实现类似MFC的映射功能，把new，maolloc等函数映射到_malloc_dbg函数上。这里我不再赘述，你可以参考MFC的源代码。<BR><BR>　　由于Debug Function实现在MS C-RuntimeLibrary中，所以它只能检测到堆内存的泄漏，而且只限于malloc，realloc或strdup等分配的内存，而那些系统资源，比如HANDLE，GDI Object，或是不通过C-Runtime Library分配的内存，比如VARIANT，BSTR的泄漏，它是无法检测到的，这是这种检测法的一个重大的局限性。另外，为了能记录内存块是在哪里分配的，源代码必须相应的配合，这在调试一些老的程序非常麻烦，毕竟修改源代码不是一件省心的事，这是这种检测法的另一个局限性。<BR><BR>　　对于开发一个大型的程序，MS C-Runtime Library提供的检测功能是远远不够的。接下来我们就看看外挂式的检测工具。我用的比较多的是BoundsChecker，一则因为它的功能比较全面，更重要的是它的稳定性。这类工具如果不稳定，反而会忙里添乱。到底是出自鼎鼎大名的NuMega，我用下来基本上没有什么大问题。<BR><BR><div id="numpage">共3页。 <font face="Webdings">9</font> 1 2 3 <font face="Webdings">:</font>　　使用BoundsChecker检测内存泄漏：<BR><BR>　　BoundsChecker采用一种被称为 Code Injection的技术，来截获对分配内存和释放内存的函数的调用。简单地说，当你的程序开始运行时，BoundsChecker的DLL被自动载入进程的地址空间（这可以通过system-level的Hook实现），然后它会修改进程中对内存分配和释放的函数调用，让这些调用首先转入它的代码，然后再执行原来的代码。BoundsChecker在做这些动作的时，无须修改被调试程序的源代码或工程配置文件，这使得使用它非常的简便、直接。<BR><BR>　　这里我们以malloc函数为例，截获其他的函数方法与此类似。<BR><BR>　　需要被截获的函数可能在DLL中，也可能在程序的代码里。比如，如果静态连结C-Runtime Library，那么malloc函数的代码会被连结到程序里。为了截获住对这类函数的调用，BoundsChecker会动态修改这些函数的指令。<BR><BR>　　以下两段汇编代码，一段没有BoundsChecker介入，另一段则有BoundsChecker的介入：<BR><BR>

<TBODY>

<TR>

<TD>126: _CRTIMP void * __cdecl malloc (<BR>127: size_t nSize<BR>128: )<BR>129: {<BR><BR>00403C10 push ebp<BR>00403C11 mov ebp,esp<BR>130: return _nh_malloc_dbg(nSize, _newmode, _NORMAL_BLOCK, NULL, 0);<BR>00403C13 push 0<BR>00403C15 push 0<BR>00403C17 push 1<BR>00403C19 mov eax,[__newmode (0042376c)]<BR>00403C1E push eax<BR>00403C1F mov ecx,dword ptr [nSize]<BR>00403C22 push ecx<BR>00403C23 call _nh_malloc_dbg (00403c80)<BR>00403C28 add esp,14h<BR>131: }</TD></TR></TBODY></TABLE><BR>　　以下这一段代码有BoundsChecker介入：<BR><BR>

<TBODY>

<TR>

<TD>126: _CRTIMP void * __cdecl malloc (<BR>127: size_t nSize<BR>128: )<BR>129: {<BR><BR>00403C10 jmp 01F41EC8<BR>00403C15 push 0<BR>00403C17 push 1<BR>00403C19 mov eax,[__newmode (0042376c)]<BR>00403C1E push eax<BR>00403C1F mov ecx,dword ptr [nSize]<BR>00403C22 push ecx<BR>00403C23 call _nh_malloc_dbg (00403c80)<BR>00403C28 add esp,14h<BR>131: }</TD></TR></TBODY></TABLE><BR>　　当BoundsChecker介入后，函数malloc的前三条汇编指令被替换成一条jmp指令，原来的三条指令被搬到地址01F41EC8处了。当程序进入malloc后先jmp到01F41EC8，执行原来的三条指令，然后就是BoundsChecker的天下了。大致上它会先记录函数的返回地址（函数的返回地址在stack上，所以很容易修改），然后把返回地址指向属于BoundsChecker的代码，接着跳到malloc函数原来的指令，也就是在00403c15的地方。当malloc函数结束的时候，由于返回地址被修改，它会返回到BoundsChecker的代码中，此时BoundsChecker会记录由malloc分配的内存的指针，然后再跳转到到原来的返回地址去。<BR><BR>　　如果内存分配/释放函数在DLL中，BoundsChecker则采用另一种方法来截获对这些函数的调用。BoundsChecker通过修改程序的DLL Import Table让table中的函数地址指向自己的地址，以达到截获的目的。<BR><BR>　　截获住这些分配和释放函数，BoundsChecker就能记录被分配的内存或资源的生命周期。接下来的问题是如何与源代码相关，也就是说当BoundsChecker检测到内存泄漏，它如何报告这块内存块是哪段代码分配的。答案是调试信息（Debug Information）。当我们编译一个Debug版的程序时，编译器会把源代码和二进制代码之间的对应关系记录下来，放到一个单独的文件里(.pdb)或者直接连结进目标程序，通过直接读取调试信息就能得到分配某块内存的源代码在哪个文件，哪一行上。使用Code Injection和Debug Information，使BoundsChecker不但能记录呼叫分配函数的源代码的位置，而且还能记录分配时的Call Stack，以及Call Stack上的函数的源代码位置。这在使用像MFC这样的类库时非常有用，以下我用一个例子来说明：<BR><BR><BR>

<TBODY>

<TR>

<TD>void ShowXItemMenu()<BR>{<BR>　…<BR>　CMenu menu;<BR><BR>　menu.CreatePopupMenu();<BR>　//add menu items.<BR>　menu.TrackPropupMenu();<BR>　…<BR>}<BR><BR>void ShowYItemMenu( )<BR>{<BR>　…<BR>　CMenu menu;<BR>　menu.CreatePopupMenu();<BR>　//add menu items.<BR>　menu.TrackPropupMenu();<BR>　menu.Detach();//this will cause HMENU leak<BR>　…<BR>}<BR><BR>BOOL CMenu::CreatePopupMenu()<BR>{<BR>　…<BR>　hMenu = CreatePopupMenu();<BR>　…<BR>}</TD></TR></TBODY></TABLE><BR>　　当调用ShowYItemMenu()时，我们故意造成HMENU的泄漏。但是，对于BoundsChecker来说被泄漏的HMENU是在class CMenu::CreatePopupMenu()中分配的。假设的你的程序有许多地方使用了CMenu的CreatePopupMenu()函数，如CMenu::CreatePopupMenu()造成的，你依然无法确认问题的根结到底在哪里，在ShowXItemMenu()中还是在ShowYItemMenu()中，或者还有其它的地方也使用了CreatePopupMenu()？有了Call Stack的信息，问题就容易了。BoundsChecker会如下报告泄漏的HMENU的信息：<BR><BR>

<TBODY>

<TR>

<TD>Function<BR>File<BR>Line<BR><BR>CMenu::CreatePopupMenu<BR>E:\8168\vc98\mfc\mfc\include\afxwin1.inl<BR>1009<BR><BR>ShowYItemMenu<BR>E:\testmemleak\mytest.cpp<BR>100</TD></TR></TBODY></TABLE><BR>　　这里省略了其他的函数调用<BR><BR>　　如此，我们很容易找到发生问题的函数是ShowYItemMenu()。当使用MFC之类的类库编程时，大部分的API调用都被封装在类库的class里，有了Call Stack信息，我们就可以非常容易的追踪到真正发生泄漏的代码。<BR><BR>　　记录Call Stack信息会使程序的运行变得非常慢，因此默认情况下BoundsChecker不会记录Call Stack信息。可以按照以下的步骤打开记录Call Stack信息的选项开关：<BR><BR>　　1. 打开菜单：BoundsChecker|Setting… <BR><BR>　　2. 在Error Detection页中，在Error Detection Scheme的List中选择Custom<BR><BR>　　3. 在Category的Combox中选择 Pointer and leak error check<BR><BR>　　4. 钩上Report Call Stack复选框<BR><BR>　　5. 点击Ok<BR><BR>　　基于Code Injection，BoundsChecker还提供了API Parameter的校验功能，memory over run等功能。这些功能对于程序的开发都非常有益。由于这些内容不属于本文的主题，所以不在此详述了。<BR><BR>　　尽管BoundsChecker的功能如此强大，但是面对隐式内存泄漏仍然显得苍白无力。所以接下来我们看看如何用Performance Monitor检测内存泄漏。<BR><BR>　　使用Performance Monitor检测内存泄漏<BR><BR>　　NT的内核在设计过程中已经加入了系统监视功能，比如CPU的使用率，内存的使用情况，I/O操作的频繁度等都作为一个个Counter，应用程序可以通过读取这些Counter了解整个系统的或者某个进程的运行状况。Performance Monitor就是这样一个应用程序。<BR><BR>　　为了检测内存泄漏，我们一般可以监视Process对象的Handle Count，Virutal Bytes 和Working Set三个Counter。Handle Count记录了进程当前打开的HANDLE的个数，监视这个Counter有助于我们发现程序是否有Handle泄漏；Virtual Bytes记录了该进程当前在虚地址空间上使用的虚拟内存的大小，NT的内存分配采用了两步走的方法，首先，在虚地址空间上保留一段空间，这时操作系统并没有分配物理内存，只是保留了一段地址。然后，再提交这段空间，这时操作系统才会分配物理内存。所以，Virtual Bytes一般总大于程序的Working Set。监视Virutal Bytes可以帮助我们发现一些系统底层的问题; Working Set记录了操作系统为进程已提交的内存的总量，这个值和程序申请的内存总量存在密切的关系，如果程序存在内存的泄漏这个值会持续增加，但是Virtual Bytes却是跳跃式增加的。<BR><BR>　　监视这些Counter可以让我们了解进程使用内存的情况，如果发生了泄漏，即使是隐式内存泄漏，这些Counter的值也会持续增加。但是，我们知道有问题却不知道哪里有问题，所以一般使用Performance Monitor来验证是否有内存泄漏，而使用BoundsChecker来找到和解决。<BR><BR>　　当Performance Monitor显示有内存泄漏，而BoundsChecker却无法检测到，这时有两种可能：第一种，发生了偶发性内存泄漏。这时你要确保使用Performance Monitor和使用BoundsChecker时，程序的运行环境和操作方法是一致的。第二种，发生了隐式的内存泄漏。这时你要重新审查程序的设计，然后仔细研究Performance Monitor记录的Counter的值的变化图，分析其中的变化和程序运行逻辑的关系，找到一些可能的原因。这是一个痛苦的过程，充满了假设、猜想、验证、失败，但这也是一个积累经验的绝好机会。<BR><BR>　　总结<BR><BR>　　内存泄漏是个大而复杂的问题，即使是Java和.Net这样有Gabarge Collection机制的环境，也存在着泄漏的可能，比如隐式内存泄漏。由于篇幅和能力的限制，本文只能对这个主题做一个粗浅的研究。其他的问题，比如多模块下的泄漏检测，如何在程序运行时对内存使用情况进行分析等等，都是可以深入研究的题目。如果您有什么想法，建议或发现了某些错误，欢迎和我交流。 <div id="numpage">共3页。 <font face="Webdings">9</font> 1 2 3<script type="text/javascript">
</script>
<script type="text/javascript"
src="http://pagead2.googlesyndication.com/pagead/show_ads.js">
</script>　　对于一个c/c  程序员来说，内存泄漏是一个常见的也是令人头疼的问题。已经有许多技术被研究出来以应对这个问题，比如Smart Pointer，Garbage Collection等。Smart Pointer技术比较成熟，STL中已经包含支持Smart Pointer的class，但是它的使用似乎并不广泛，而且它也不能解决所有的问题；Garbage Collection技术在Java中已经比较成熟，但是在c/c  领域的发展并不顺畅，虽然很早就有人思考在C  中也加入GC的支持。现实世界就是这样的，作为一个c/c  程序员，内存泄漏是你心中永远的痛。不过好在现在有许多工具能够帮助我们验证内存泄漏的存在，找出发生问题的代码。<BR><BR>　　<STRONG>内存泄漏的定义</STRONG> <BR><BR>　　一般我们常说的内存泄漏是指堆内存的泄漏。堆内存是指程序从堆中分配的，大小任意的（内存块的大小可以在程序运行期决定），使用完后必须显示释放的内存。应用程序一般使用malloc，realloc，new等函数从堆中分配到一块内存，使用完后，程序必须负责相应的调用free或delete释放该内存块，否则，这块内存就不能被再次使用，我们就说这块内存泄漏了。以下这段小程序演示了堆内存发生泄漏的情形：<BR><BR>

<TBODY>

<TR>

<TBODY>

<TR>

<TBODY>

<TR>

<TBODY>

<TR>

查看全文
发表于:2008-04-25 ┆ 阅读(25) ┆ 评论(0)

C/C 中动态链接库的创建和调用

查看全文
发表于:2008-04-25 ┆ 阅读(79) ┆ 评论(0)

\|\|	<<	>>	\|\|