C语言断言assert的用法

assert的用法

assert();

当expression结果为“假”时，会在stderr中输出这条语句所在的文件名和行号，以及这条表达式。这只在调试版本中起作用，在Release版本中不会产生任何代码。

通常当我们使用assert时，都在强烈说明一个含义：在这里必然如此。它通常用于一个函数的先验条件和后验条件的检查。比如我写一个C风格复制字符串的函数，并且认为调用者不应该传入NULL指针：

char*clone_string(constchar*source) {

char*result;

assert(source!=NULL);

result=(char*)malloc(strlen(source)+1); if(result!=NULL) {

strcpy(result,source);

assert(strcmp(result,source)==0); }

returnresult;

1 / 6

}

注意到我对source是否为NULL是用assert检查的，但对result是不是为NULL是用if语句判断的，这是因为在调用代码正确的情况下source必然不为NULL，如果断言失败，说明调用代码中有错误，需要修改；但result作为malloc的返回值则不一定，在malloc代码无误的情况下仍然可能返回NULL——当内存块不足时。最后又用assert对strcpy的结果进行检查，因为只要代码正确，无论什么情况strcpy应该正常完成复制，它没有malloc那种异常情况存在。

在《编程精粹》第二章（自己设计并使用断言）开始的一段话把assert的用途说的很清楚：利用编译程序自动查错固然好，但我敢说只要你观察一下项目中那些比较明显的错误，就会发现编译程序所查出的只是其中的一小部分。我还敢说，如果排除掉了程序中的所有错误那么在大部分时间内程序都会正确工作。

还记得第1章中的下面代码吗？

strCopy=memcpy(malloc(length),str,length);

该语句在多数情况下都会工作得很好，除非malloc的调用产生失败。当malloc失败时，就会给memcpy返回一个NULL指针。由于memcpy处理不了NULL指针，所以出现了错误。如果你很走运，在交付之前这个错误导致程序的瘫痪，从而暴露出来。但是如果你不走运，没有及时地发现这个错误，那某位顾客就一定会“走运”了。编译程序查不出这种或其他类似的错误。同样，编译程序也查不出算法的错误，无法验证程序员所作的假定。或者更一般地，编译程序也查不出所传递的参数是否有效。

寻找这种错误非常艰苦，只有技术非常高的程序员或者测试者才能将它们根除并且不会引起其他的问题。

然而假如你知道应该怎样去做的话，自动寻找这种错误就变得很容易了。 两个版本的故事

2 / 6

让我们直接进入memcpy，看看怎样才能查出上面的错误。最初的解决办法是使memcpy对NULL指针进行检查，如果指针为NULL，就给出一条错误信息，并中止memcpy的执行。

下面是这种解法对应的程序。

voidmemcpy(void*pvTo,void*pvFrom,size_tsize) {

void*pbTo=(byte*)pvTo; void*pbFrom=(byte*)pvFrom; if(pvTo==NULL||pvFrom==NULL) {

fprintf(stderr,“Badargsinmemcpy\\n”); abort(); }

while(size-->0)

*pbTo++==*pbFrom++; return(pvTo); }

只要调用时错用了NULL指针，这个函数就会查出来。所存在的唯一问题是其中的测试代码使整个函数的大小增加了一倍，并且降低了该函数的执行速度。如果说这是“越治病越糟”，确实有理，因

3 / 6

为它一点不实用。要解决这个问题需要利用C的预处理程序。

如果保存两个版本怎么样？一个整洁快速用于程序的交付；另一个臃肿缓慢件（因为包括了额外的检查），用于调试。这样就得同时维护同一程序的两个版本，并利用C的预处理程序有条件地包含或不包含相应的检查部分。

voidmemcpy(void*pvTo,void*pvFrom,size_tsize) {

void*pbTo=(byte*)pvTo; void*pbFrom=(byte*)pvFrom; #ifdefDEBUG

if(pvTo==NULL||pvFrom==NULL) {

fprintf(stderr,“Badargsinmemcpy\\n”); abort(); } #endif

while(size-->0)

*pbTo++==*pbFrom++; return(pvTo);

4 / 6

}

这种想法是同时维护调试和非调试（即交付）两个版本。在程序的编写过程中，编译其调试版本，利用它提供的测试部分在增加程序功能时自动地查错。在程序编完之后，编译其交付版本，封装之后交给经销商。

当然，你不会傻到直到交付的最后一刻才想到要运行打算交付的程序，但在整个的开发工程中，都应该使用程序的调试版本。正如在这一章和下一章所建，这样要求的主要原因是它可以显著地减少程序的开发时间。读者可以设想一下：如果程序中的每个函数都进行一些最低限度的错误检查，并对一些绝不应该出现的条件进行测试的活，相应的应用程序会有多么健壮。

这种方法的关键是要保证调试代码不在最终产品中出现。 利用断言进行补救

说老实话memcpy中的调试码编得非常蹩脚，且颇有点喧宾夺主的意味。因此尽管它能产生很好的结果，多数程序员也不会容忍它的存在，这就是聪明的程序员决定将所有的调试代码隐藏在断言assert中的缘故。assert是个宏，它定义在头文件assert.h中。assert虽然不过是对前面所见＃ifdef部分代码的替换，但利用这个宏，原来的代码从7行变成了1行。

voidmemcpy(void*pvTo,void*pvFrom,size_tsize) {

void*pbTo=(byte*)pvTo; void*pbFrom=(byte*)pvFrom;

assert(pvTo!=NULL&&pvFrom!=NULL); while(size-->0)

5 / 6

*pbTo++==*pbFrom++; return(pvTo); }

aasert是个只有定义了DEBUG才起作用的宏，如果其参数的计算结果为假，就中止调用程序的执行。因此在上面的程序中任何一个指针为NULL都会引发assert。

assert并不是一个仓促拼凑起来的宏，为了不在程序的交付版本和调试版本之间引起重要的差别，需要对其进行仔细的定义。宏assert不应该弄乱内存，不应该对未初始化的数据进行初始化，即它不应该产主其他的副作用。正是因为要求程序的调试版本和交付版本行为完全相同，所以才不把assert作为函数，而把它作为宏。如果把assert作为函数的话，其调用就会引起不期望的内存或代码的兑换。要记住，使用assert的程序员是把它看成一个在任何系统状态下都可以安全使用的无害检测手段

6 / 6