zoukankan      html  css  js  c++  java
  • 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##"
    Problem: "##expr_desc))) 
        _CrtDbgBreak();}while(0)
    #endif

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

     

    四、断言使用准则(推荐)

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

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

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

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

    • 断言不能够检查哪些可能正确也可能错误的情况。正确运行的程序不会使任何断言生效,如果发生断言失效的情况,则程序一定存在某种错误。
    • 断言不是防御性编程的替代品。断言不能防止程序的发布版本崩溃。
    • 断言不能检查哪些不是实现方面的错误。这些非实现方面的错误包括用户输入错误、资源分配错误、文件系统错误以及硬件错误。断言不是异常处理、返回值或其他形式的错误处理的替代品。
    • 断言不能够向用户报告错误。
    • 断言不能不能包含程序代码,不能有副作用。断言不能修改变量,也不能调用修改程序变量的函数。
  • 相关阅读:
    linux上部署javaWeb项目
    Android 调试native的crash和anr
    你怎么知道你的网站K
    Win 10开门人类智慧的世界领先
    Preference如何增加在activity生命周期监听器
    智能指针模板,要管理动态分配的内存
    两分钟找到一些注意事项
    javascript---在自由落体实现
    URAL 1934 Black Spot --- 最短的简单修改
    最简单的ADABOOST人脸检测程序。COPY执行,前提是你配置OpenCV周围环境
  • 原文地址:https://www.cnblogs.com/tocy/p/4098245.html
Copyright © 2011-2022 走看看