Windows下断言的类型及实现

时间:2024-03-11 07:55:11

一、内容综述

本文主要介绍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. 什么情况下不能使用断言?

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