assert 断言函数

在我们的实际开发过程之中，常常会出现一些隐藏得很深的 BUG，或者是一些概率性发生的 BUG，通常这些 BUG 在我们调试的过程中不会出现很明显的问题，但是如果我们将其发布，在用户的各种运行环境下，这些程序可能就会露出马脚了。那么，如何让我们的程序更明显的暴露出问题呢？这种情况下，我们一般都会使用 assert 断言函数，这是 C 语言标准库提供的一个函数，也就是说，它的使用与操作系统平台，调试器种类无关。我们只要学会了它的使用，便可一次使用，处处开花。

接下来我们来了解一下 assert 函数的用法，这个函数在 assert.h 头文件中被定义，在微软的 cl 编译器中它的原型是这样的：

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

我们看到 assert 在 cl 编译器中被包装成了一个宏，实际调用的函数是 _wassert ，不过在一些编译器中，assert 就是一个函数。为了避免这些编译器差异带来的麻烦，我们就统一将 assert 当成一个函数使用。

我们来了解一下 assert 函数的用法和运行机制，assert 函数的用法很简单，我们只要传入一个表达式即可，它会计算我们传入的表达式的结果，如果为真，则不会有任何操作，但是如果我们传入的表达式的计算结果为假，它就会像 stderr （标准错误输出）打印一条错误信息，然后调用 abort 函数直接终止程序的运行。

现在我们在 Visual Studio 中创建一个工程，输入下面这段非常简单的代码：

#include <stdio.h>
#include <assert.h>
int main()
{
    printf("assert 函数测试:");
    assert(true); //表达式为真
    assert(1 >= 2); //表达式为假
    return 0;
}

我们按 F5 启动调试：

我们看到,我们的输出窗口打印出了断言失败的信息，并且 Visual Studio 弹出了一个对话框询问我们是否继续执行。但是如果我们不绑定调试器，构建发布版程序，按 Ctrl + F5 直接运行呢?是的，这个 assert 语句就无效了，原因其实很简单，我们看看 assert.h 头文件中的这部分代码：

#ifdef NDEBUG
#define assert(_Expression)     ((void)0)
#else  /* NDEBUG */

我们看到，只要我们定义了 NDEBUG 宏，assert 就会失效，而 Visual Studio 的默认的发布版程序编译参数中定义了 NDEBUG 宏，所以我们不用额外定义，但是在其他编译器中，我们在发布程序的时候就必须在包含 assert.h 头文件前定义 NDEBUG 宏，避免 assert 生效，否则总是让用户看到“程序已经停止运行，正在寻找解决方案 . . .”的 Windows 系统对话框可就不妙了。

下面我们来了解一下 assert 的常用情境以及一些注意事项。举个 C 语言文件操作的例子：

#include <stdio.h>
#include <assert.h>
#include <stdlib.h>

int main(void)
{
    FILE *fpoint;
    fpoint = fopen("存在的文件.txt", "w");
    //以可读写的方式打开一个文件
    //如果文件不存在就自动创建一个同名文件
    assert(fpoint);                        
    //（第一次断言）所以这里断言成功
    fclose(fpoint);
    fpoint = fopen("不存在的文件.txt", "r");
    //以只读的方式打开一个文件，如果不存在就打开文件失败
    assert(fpoint);
    //（第二次断言）所以断言失败
    printf("文件打开成功");
    //程序永远都执行不到这里来
    fclose(fpoint);                          
    return 0;
}

阅读代码，我们可以知道，如果我们错误的设置了读写权限，或者没有考虑 Windows 7(或更高版本 ) 的 UAC(用户账户权限控制 ) 问题的话，我们的程序出现的问题就很容易在我们的测试中暴露出来。事实上，上面的代码也不是一定能通过第一次断言的，我们把构建生成的（Debug 模式的）可执行文件复制到我们的系统盘的 Program Files 文件夹再执行，那么 Win7 及以上的操作系统的 UAC 都会导致程序无法通过第一次断言的。所以在这种情况下我们就需要在必要的情况申请管理员权限避免程序 BUG 的发生。

在我们的实际使用过程中，我们需要注意一些使用 assert 的问题。首先我们看看下面的这个断言语句：

//...
assert( c1 /*条件1*/ && c2 /*条件2*/ );
//...

我们思考一下：如果我们的程序在这里断言失败了，我们如何知道是 c1 断言失败还是 c2 断言失败呢，答案是：没有办法。在这里我们应该遵循使用 assert 函数的第一个原则：每次断言只能检验一个条件，所以上面的代码应该改成这样:

//...
assert(c1 /*条件1*/);
assert(c2 /*条件2*/);
//...

这样，一旦出现问题，我们就可以通过行号知道是哪个条件断言失败了。

接下来我们来思考一个问题：我们可以使用 assert 语句代替我们的条件过滤语句么？我们来举个例子，我们写了一个视频格式转换器，我们本应输出标准 MP4 格式的视频，但是由于编码解码库的问题，我们在转换过程中出现了错误，像这种情况下，我们能否用 assert 代替掉我们的 if 语句呢（假设这里忽略了 Visual Studio 发布版程序编译过程中自动定义的 NDEBUG 宏）？很明显，这样做是不可以的。这是为什么呢？

现在我们来区分一下程序中的错误与异常，所谓错误，是代码编写途中的缺陷导致的，是程序运行中可以用 if 语句检测出来的。而异常在我们的 C 语言中，一般也可以使用 if 语句判断，并进行对应的处理。而 assert 是用来判断我们程序中的代码级别的错误的。像用户输入错误，调用其他函数库错误，这些问题我们都是可以用 if 语句检测处理的。另一方面，使用 if 语句的程序对用户更友好。

下面我们通过代码展示使用 assert 的另外一个注意意事项，我们新建一个工程，输入如下代码:

#include <stdio.h>
#include <assert.h>
int main(void)
{
    int i = 0;
    for ( ; ; )
    {
        assert(i++ <= 100);
        printf("我是第%d行\n",i);
    }
    return 0;
}

我们按 F5 运行调试器，我们会看到这样的情景：

这是正常的，我们按 Shift + F5 终止调试，接下来，我们切换一下编译模式到发布模式：

接下来我们按 Ctrl+F5 不绑定调试器直接运行：

我们看到了一个完全不相同的运行结果，这是为什么呢？其实原因很简单，我们注意这段代码：

assert(i++ <= 100);

我们的条件表达式为 i++ <= 100，这个表达式会更改我们的运行环境(变量 i 的值 )，在发布版程序中，所有的 assert 语句都会失效，那么这条语句也就被忽略了，但是我们可以把它改为 i++ ; assert(i <= 100); ，这样程序就能正常运行了。所以请记住：不要使用会改变环境的语句作为断言函数的参数，这可能导致实际运行中出现问题。

最后，我们再来探讨一下，什么时候应该用 assert 语句？一个健壮的程序，都会有 30%~50%的错误处理代码，几乎用不上 assert 断言函数，我们应该将 assert 用到那些极少发生的问题下，比如 Object* pObject = new Object，返回空指针，这一般都是指针内存分配出错导致的，不是我们可以控制的。这时即使你使用了容错语句，后面的代码也不一定能够正常运行，所以我们也就只能停止运行报错了。

意见反馈

C语言教程

编程基础

C 语言初探

变量和数据类型

C 语言输入输出

循环结构和选择结构

C 语言数组

C 语言函数

预处理命令

指针

结构体

重要知识点补充

文件操作

C 语言调试

assert 断言函数