Windows下断言的类型及实现

一、内容综述

本文主要介绍Windows下断言assert的实现，并总结断言的不同应用准则。最后给出一个windows自定义断言的方法。

本文行文参考《Debugging Windows Programs》第三章相关内容，如果有兴趣的话建议读者可以深入阅读下。

 

二、断言的类型

 1.  ANSI C 断言

 ANSI C断言指的是assert函数，按照标准定义，assert是支持跨平台的，原型如下：

void assert (int expression);

C语言标准中规定，编译器实现的断言失败消息至少包含以下信息：

Assertion failed: expression（断言失败的参数）, file filename（源文件名称）, line line number（断言失败的行号）。

另外，C语言标准中支持，在包含<assert.h>或<cassert>头文件之前定义NDEBUG宏，可禁用assert函数的断言判断。

更加详细的信息可参考：http://www.cplusplus.com/reference/cassert/assert/

Windows下assert函数，在控制台程序和基于Windows的程序下弹窗差别较大。比如在我的pc下（Win7，vs2010，debug编译），控制台程序使用stderr显示断言消息，并弹出Debug Error的窗口。

 而在MFC中弹窗如下：

 二者断言失败的表现不太相同，但均符合C语言标准的规定。

从上面两个截图也可以看出，当源文件路径比较长时，assert断言的消息提示会把文件路径截断为短路径格式，这样很不容易定位出问题的代码。因此，在Windows下不推荐直接使用assert断言函数。

其他更详细的assert信息，可参考：http://msdn.microsoft.com/en-us/library/9sb57dw4.aspx。

如下代码给出了，vs2010中assert函数的头文件声明（assert.h头文件）

#include <crtdefs.h>



#undef  assert



#ifdef  NDEBUG



#define assert(_Expression)     ((void)0)



#else



#ifdef  __cplusplus

extern "C" {

#endif



_CRTIMP void __cdecl _wassert(_In_z_ const wchar_t * _Message, _In_z_ const wchar_t *_File, _In_ unsigned _Line);



#ifdef  __cplusplus

}

#endif



#define assert(_Expression) (void)( (!!(_Expression)) || (_wassert(_CRT_WIDE(#_Expression), _CRT_WIDE(__FILE__), __LINE__), 0) )



#endif  /* NDEBUG */

View Code

从中也可以看出NDEBUG宏为什么可以影响assert断言了。

2.  C-Runtime Library断言

 C Runtime Library(CRT)提供了_ASSERT、_ASSERTE两种形式的断言，位于<crtdbg.h>头文件中。_ASSERT、_ASSERTE函数仅在_DEBUG宏定义的情况下有效，这也是vs的debug版本中预定义宏_DEBUG的作用。

另外，这两个函数在控制台程序和基于Windows的应用程序下断言失败的提示消息框是一样的。

_ASSERT会弹出如下所示的断言失败提示框

 _ASSERT断言失败提示框如下：

 

对比两个对话框，_ASSERTE相比_ASSERT多了关于断言失败表达式的信息。这样可以在不查看源代码的情况下分析断言失败的原因，但是过多调用_ASSERTE会使debug版本的可执行程序中保存大量关于断言失败的表达式字符串，文件较大。

下面代码是vs2010中crtdbg.h头文件给出的关于_ASSERTE、_ASSERT的声明，可以参考下

 

// 摘录版本，只给出_ASSERT、_ASSERTE的相关部分

#ifndef _DEBUG

/*  We allow our basic _ASSERT macros to be overridden by pre-existing definitions. 

    This is not the ideal mechanism, but is helpful in some scenarios and helps avoid

    multiple definition problems */

#ifndef _ASSERT

#define _ASSERT(expr) ((void)0)

#endif 



#ifndef _ASSERTE

#define _ASSERTE(expr) ((void)0)

#endif



#else

/* Asserts */

/* We use !! below to ensure that any overloaded operators used to evaluate expr do not end up at operator || */

#define _ASSERT_EXPR(expr, msg) \

        (void) ((!!(expr)) || \

                (1 != _CrtDbgReportW(_CRT_ASSERT, _CRT_WIDE(__FILE__), __LINE__, NULL, msg)) || \

                (_CrtDbgBreak(), 0))



#ifndef _ASSERT

#define _ASSERT(expr)   _ASSERT_EXPR((expr), NULL)

#endif



#ifndef _ASSERTE

#define _ASSERTE(expr)  _ASSERT_EXPR((expr), _CRT_WIDE(#expr))

#endif



#if     !defined(_CRT_PORTABLE)

#define _CrtDbgBreak() __debugbreak()

#else

_CRTIMP void __cdecl _CrtDbgBreak(

        void

        );

#endif



#endif

View Code

 

如果有兴趣深入了解，可以参考：http://msdn.microsoft.com/en-us/library/ezb1wyez.aspx。

3. MFC断言

 MFC中，我用的最多的是VERIFY、ASSERT两个断言。

ASSERT和VERIFY断言失败的弹窗和_ASSERT相关，首先看下ASSERT、VERIFY的实现。代码来自vs2010的相关头文件

// from afxassert.cpp

#ifdef _DEBUG   // entire file



// NOTE: in separate module so it can replaced if needed



BOOL AFXAPI AfxAssertFailedLine(LPCSTR lpszFileName, int nLine)

{

#ifndef _AFX_NO_DEBUG_CRT

    // we remove WM_QUIT because if it is in the queue then the message box

    // won't display

    MSG msg;

    BOOL bQuit = PeekMessage(&msg, NULL, WM_QUIT, WM_QUIT, PM_REMOVE);

    BOOL bResult = _CrtDbgReport(_CRT_ASSERT, lpszFileName, nLine, NULL, NULL);

    if (bQuit)

        PostQuitMessage((int)msg.wParam);

    return bResult;

#else

    // Not supported.

#error _AFX_NO_DEBUG_CRT is not supported.

#endif // _AFX_NO_DEBUG_CRT

}

#endif // _DEBUG



// from afxver_.h

#ifndef AfxDebugBreak

#define AfxDebugBreak() __debugbreak()

#endif



#ifndef _DEBUG

#ifdef AfxDebugBreak

#undef AfxDebugBreak

#endif

#define AfxDebugBreak()

#endif  // _DEBUG







// from afx.h

#ifdef _DEBUG

BOOL AFXAPI AfxAssertFailedLine(LPCSTR lpszFileName, int nLine);



#define THIS_FILE          __FILE__

#define VERIFY(f)          ASSERT(f)

#define DEBUG_ONLY(f)      (f)



#else   // _DEBUG



#define VERIFY(f)          ((void)(f))

#define DEBUG_ONLY(f)      ((void)0)



#endif // !_DEBUG



#define ASSERT(f)          DEBUG_ONLY((void) ((f) || !::AfxAssertFailedLine(THIS_FILE, __LINE__) || (AfxDebugBreak(), 0)))

View Code

最终调用__debugbreak（编译器内部提供的函数）。

从上面的源码中也可看出ASSERT和VERIFY的区别，_DEBUG宏定义的情况下二者完全功能和实现一样；_DEBUG宏未定义的情况下，ASSERT将直接忽略断言条件，而VERIFY会执行以下断言条件语句。需要说明的是VERIFY也是断言的一种，在Release模式下（通常_DEBUG宏不会定义）断言是失效的，所以不推荐使用VERIFY用于判断可能发生的错误，更进一步不推荐使用VERIFY，VERIFY对防御性编程有过多的误导作用。

三、自定义断言

 如果windows提供的断言不能够或者不适合与实际需要，可以自定义断言的形式来提供更加自由的错误跟踪体系，通常自定义断言出于以下考虑

• 不同类型的程序提供可移植性，比如mfc、console、windows api、跨平台需要。
• 简化事后调试及问题跟踪，在错误发生时提供调用堆栈。
• 不同的错误处理策略，比如不想看到系统弹出错误提示，而换用其他异常处理逻辑。

当然，也可能有其他要求。但是这里仅提供一种自定义断言的方法，至于是否合适、是否需要重定义断言还是需要读者自己决定。通过上面第二部分关于断言的介绍，显然自己写断言处理并不复杂，可使用_CrtDbgReport和_CrtDgbBreak即可完成多数断言工作。比如类似如下代码的断言实现：

// 多字节版本，使用Unicode需要修改调用函数

#ifndef _DEBUG

#define VASSERT(expr, expr_desc) ((void)0)

#else

#define VASSERT(expr, expr_desc) \

    do { if (!(expr) && \

    (1 == _CrtDbgReport(_CRT_ASSERT, (__FILE__), __LINE__, \

    NULL, #expr##"\nProblem: "##expr_desc))) \

    _CrtDbgBreak();}while(0)

#endif

仅供参考的代码，功能相对比较简单。

 

四、断言使用准则（推荐）

 1. 什么情况下需要使用断言？

断言仅用于检查有效性，而不是正确性。也就是说即使程序有错误，断言要做的是发现错误，在错误经过断言时能够报告程序中有错误，而不是报告程序不正确。断言是给开发人员使用的代码诊断的有效工具。断言通常用于以下几种情况：

• 检查函数输入（前置条件）。验证函数参数、成员变量、全局变量，以及其他可能使用的变量状态。
• 检查函数输出（后置条件）。特别是在经过特殊而复杂的处理逻辑之后，检查输出参数、对象成员的有效性。
• 检查对象当前状态。比如对象是否被正常初始化、当前状态是否允许指定函数调用或者输入。
• 检查逻辑变量的合理性和一致性。包括循环不变量、计数器、偏移变量、不可能出现的值、不可能出现的情况以及某些固定的关系等。
• 检查类的不变量。

2. 什么情况下不能使用断言？

• 断言不能够检查哪些可能正确也可能错误的情况。正确运行的程序不会使任何断言生效，如果发生断言失效的情况，则程序一定存在某种错误。
• 断言不是防御性编程的替代品。断言不能防止程序的发布版本崩溃。
• 断言不能检查哪些不是实现方面的错误。这些非实现方面的错误包括用户输入错误、资源分配错误、文件系统错误以及硬件错误。断言不是异常处理、返回值或其他形式的错误处理的替代品。
• 断言不能够向用户报告错误。
• 断言不能不能包含程序代码，不能有副作用。断言不能修改变量，也不能调用修改程序变量的函数。