《C语言断言assert的用法》由会员分享，可在线阅读，更多相关《C语言断言assert的用法（5页珍藏版）》请在金锄头文库上搜索。
1、assert 的用法assert();当expression结果为 假”时，会在stderr中输出这条语句所在的文件名和行 号，以及这条表达式。这只在调试版本中起作用，在 Release版本中不会产生任 何代码。通常当我们使用assert时，都在强烈说明一个含义：在这里必然如此。它 通常用于一个函数的先验条件和后验条件的检查。比如我写一个C风格复制字符串的函数，并且认为调用者不应该传入NULL指针：char*clone_string(constchar*source)char*result;assert(source!=NULL);result=(char*)malloc(strlen(sou
2、rce)+1);if(result!=NULL)strcpy(result,source);assert(strcmp(result,source)=0);returnresult;注意到我对source是否为NULL是用assert检查的，但对result是不是为 NULL是用if语句判断的，这是因为在调用代码正确的情况下source必然不为NULL，如果断言失败，说明调用代码中有错误，需要修改；但 result作为 malloc的返回值则不一定，在 malloc代码无误的情况下仍然可能返回NUL 当内存块不足时。最后又用assert对strcpy的结果进行检查，因为只要代码正 确，无论什么
3、情况 strcpy 应该正常完成复制，它没有 malloc 那种异常情况存 在。在编程精粹第二章(自己设计并使用断言)开始的一段话把assert的用途说的很清楚：利用编译程序自动查错固然好，但我敢说只要你观察一下项 目中那些比较明显的错误，就会发现编译程序所查出的只是其中的一小部分。 我还敢说，如果排除掉了程序中的所有错误那么在大部分时间内程序都会正确 工作。还记得第 1 章中的下面代码吗？strCopy=memcpy(malloc(length),str,length);该语句在多数情况下都会工作得很好，除非malloc的调用产生失败。当malloc失败时，就会给 memcpy返回一个NUL
4、L指针。由于memcpy处理不了 NULL指针，所以出现了错误。如果你很走运，在交付之前这个错误导致程序的 瘫痪，从而暴露出来。但是如果你不走运，没有及时地发现这个错误，那某位 顾客就一定会 “走运”了。编译程序查不出这种或其他类似的错误。同样，编译 程序也查不出算法的错误，无法验证程序员所作的假定。或者更一般地，编译 程序也查不出所传递的参数是否有效。寻找这种错误非常艰苦，只有技术非常高的程序员或者测试者才能将它们 根除并且不会引起其他的问题。然而假如你知道应该怎样去做的话，自动寻找这种错误就变得很容易了。两个版本的故事让我们直接进入memcpy,看看怎样才能查出上面的错误。最初的解决办法
5、是使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,“ Badargsinmne”m)c;pyabort();while(size-0)*pbTo+=*pbFrom+;return(pvTo);只要调用时错用了 NULL指针，这个函数就会查出来。所
6、存在的唯一问题是 其中的测试代码使整个函数的大小增加了一倍，并且降低了该函数的执行速 度。如果说这是 “越治病越糟 ”，确实有理，因为它一点不实用。要解决这个问 题需要利用C的预处理程序。如果保存两个版本怎么样？一个整洁快速用于程序的交付；另一个臃肿缓 慢件(因为包括了额外的检查)，用于调试。这样就得同时维护同一程序的两 个版本，并利用C的预处理程序有条件地包含或不包含相应的检查部分。voidmemcpy(void*pvTo,void*pvFrom,size_tsize)void*pbTo=(byte*)pvTo;void*pbFrom=(byte*)pvFrom;#ifdefDEBUGif(
7、pvTo=NULL|pvFrom=NULL)fprintf(stderr,“ Badargsinmne”m)c;pyabort();#endifwhile(size-0)*pbTo+=*pbFrom+;return(pvTo);这种想法是同时维护调试和非调试(即交付)两个版本。在程序的编写过 程中，编译其调试版本，利用它提供的测试部分在增加程序功能时自动地查 错。在程序编完之后，编译其交付版本，封装之后交给经销商。当然，你不会傻到直到交付的最后一刻才想到要运行打算交付的程序，但 在整个的开发工程中，都应该使用程序的调试版本。正如在这一章和下一章所 建，这样要求的主要原因是它可以显著地减少程序的
8、开发时间。读者可以设想 一下：如果程序中的每个函数都进行一些最低限度的错误检查，并对一些绝不 应该出现的条件进行测试的活，相应的应用程序会有多么健壮。这种方法的关键是要保证调试代码不在最终产品中出现。利用断言进行补救说老实话 memcpy 中的调试码编得非常蹩脚，且颇有点喧宾夺主的意味。 因此尽管它能产生很好的结果，多数程序员也不会容忍它的存在，这就是聪明 的程序员决定将所有的调试代码隐藏在断言 assert 中的缘故。 assert 是个宏，它 定义在头文件assert.h中。assert虽然不过是对前面所见# ifdef部分代码的替 换，但利用这个宏，原来的代码从 7 行变成了 1 行。v
9、oidmemcpy(void*pvTo,void*pvFrom,size_tsize)void*pbTo=(byte*)pvTo;void*pbFrom=(byte*)pvFrom;assert(pvTo!=NULL&pvFrom!=NULL);while(size-0)*pbTo+=*pbFrom+;return(pvTo);aasert是个只有定义了 DEBUG才起作用的宏，如果其参数的计算结果为 假，就中止调用程序的执行。因此在上面的程序中任何一个指针为NULL都会引发 assert。assert并不是一个仓促拼凑起来的宏，为了不在程序的交付版本和调试版本 之间引起重要的差别，需要对其进行仔细的定义。宏assert不应该弄乱内存，不应该对未初始化的数据进行初始化，即它不应该产主其他的副作用。正是因 为要求程序的调试版本和交付版本行为完全相同，所以才不把assert作为函数，而把它作为宏。如果把assert作为函数的话，其调用就会引起不期望的内 存或代码的兑换。要记住，使用 assert的程序员是把它看成一个在任何系统状 态下都可以安全使用的无害检测手段
