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，并不会传入文件名和行号。

因此，我们在开发代码阶段，保留上述代码是值得的。