AssertValid和Dump函数的应用

转自 http://blog.sina.com.cn/s/blog_494684f00100fatf.html

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Dump 函数的声明如下所示：

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

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

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

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

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

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

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

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

Dumping objects ->

{5} strcore.cpp(80) : non-object block at $00A7521A, 9 bytes long
{4} strcore.cpp(80) : non-object block at $00A751F8, 5 bytes long
{3} strcore.cpp(80) : non-object block at $00A751D6, 6 bytes long
{2} a CPerson at $51A4
Last Name: Smith
First Name: Alan
Phone #: 581-0215
{1} strcore.cpp(80) : non-object block at $00A7516E, 25 bytes long
大多数行开始处的大括号中的数字指定对象的分配顺序。最近分配的对象具有最高编号，并显示在转储的顶部。

静态库和动态库的区别：
首先纠正所谓“静态连接就是把需要的库函数放进你的exe之中”的说法。在真实世界中，有三个概念：Use static libary, static linked DLL,dynamic linked DLL. 多数人混淆了static libary和static linked DLL的概念，当然他们有似是而非的“相似之处”，比如都用到.lib。
使用静态库(Use static libary)是把.lib和其他.obj一起build在目标文件中， 目标文件可以是.exe,也可以是.dll或.oxc等。
一般情况下，可以根本就没有“对应的”.dll 文件，如C Run Time(CRT)库。一个例子就是，写一个main(){}，build出来并不是只有几个字节，当然有人会说那还有exe文件头呢？是，即使加上文件 头的尺寸，build出的执行文件仍然“莫名的大”。实际上那多出来的部分就是CRT静态库。姑且可以把静态库.lib理解成外部程序的obj文件比较合 理，它包含了函数的实现。
下面再谈static linked DLL和dynamic linked DLL又如何？
静态链接(static linked DLL)从操作上在VC的Project|Settings...|Link (tab)|General (category)|Object/library modules 中设置和添加。比如要使用SDK中的PropertySheet() API, 就要在这里添加 comctl32.lib，然后再调用的源程序中#include <prsht.h>, 使用的地方直接调用PropertySheet()。当程序.exe启动时，系统会把对应comctl32.dll加载进来。作为DLL的静态引入库 的.lib不包含函数的实现，只包含用于系统加载的信息，如对应的DLL名称，函数歧视地只在对应的DLL中的便宜等等。相比动态链接而言，静态链接是很 简单的。
动态链接是使用LoadLibrary()/GetProcessAddress()和FreeLibrary().
有人会想，动态链接这样麻烦，为什么还要用呢？这里有一个技术问题，对这个问题的解决直接导致了动态加载的需求。问题是有些DLL只在某个Windows 版本中存在，或某个API只在某些Windows版本中被加入指定的DLL。当你使用静态链接的.exe试图在不支持的Windows版本上运行时，系统 会弹出系统对话框提示某某.dll无法加载或无法定位某某API的消息，然后就中止.exe的运行。像这样因为个别功能的实现依赖于某个DLL，当这个 DLL不可用时导致整个.exe无法运行是不明智的。避免这样的结局只有用动态链接。

#ifdef _DEBUG // 判断是否定义_DEBUG
#undef THIS_FILE // 取消THIS_FILE的定义
static char THIS_FILE[]=__FILE__; // 定义THIS_FILE指向文件名
#define new DEBUG_NEW // 定义调试new宏，取代new关键字
#endif // 结束
如果定义了_DEBUG，表示在调试状态下编译，因此相应修改了两个符号的定义
THIS_FILE是一个char数组全局变量，字符串值为当前文件的全路径，这样在Debug版本中当程序出错时出错处理代码可用这个变量告诉你是哪个文件中的代码有问题。
定义 _DEBUG后，由于定义了_DEBUG,编译器确定这是一个调试，编译#ifdef _DEBUG和#endif之间的代码。#undef 表示清除当前定义的宏，使得THIS_FILE无定义。__FILE__ 是编译器能识别的事先定义的ANSI C 的6个宏之一。#define new DEBUG_NEW
DEBUG_NEW定位内存泄露并且跟踪文件名.

在用vc时，利用AppWizard会产生如下代码：
#ifdef _DEBUG
#define new DEBUG_NEW
#undef THIS_FILE
static char THIS_FILE[] = __FILE__;
#endif
对于
#define new DEBUG_NEW
首先看msdn的解释：
Assists in finding memory leaks. You can use DEBUG_NEW everywhere in your program that you would ordinarily use the new operator to allocate heap storage.
In debug mode (when the _DEBUG symbol is defined), DEBUG_NEW keeps track of the filename and line number for each object that it allocates. Then, when you use the CMemoryState::DumpAllObjectsSince member function, each object allocated with DEBUG_NEW is shown with the filename and line number where it was allocated.
To use DEBUG_NEW, insert the following directive into your source files:
#define new DEBUG_NEW
Once you insert this directive, the preprocessor will insert DEBUG_NEW wherever you use new, and MFC does the rest. When you compile a release version of your program, DEBUG_NEW resolves to a simple new operation, and the filename and line number information is not generated.

再查看定义：
#ifdef _DEBUG
void* AFX_CDECL operator new(size_t nSize, LPCSTR lpszFileName, int nLine);
#define DEBUG_NEW new(THIS_FILE, __LINE__)
#else
#define DEBUG_NEW new
#endif
这样就很清楚了，当在debug模式下时，我们分配内存时的new被替换成DEBUG_NEW，而这个DEBUG_NEW不仅要传入内存块的大小，还要传入源文件名和行号，这就有个好处，即当发生内存泄漏时，我们可以在调试模式下定位到该问题代码处。若删掉该句，就不能进行定位了。而在release版本下的new就是简单的new，并不会传入文件名和行号。
因此，我们在开发代码阶段，保留上述代码是值得的。