优质C程序秘诀第2章–自己设计并使用断言.docVIP

第2章 自己设计并使用断言 利用编译程序自动查错固然好，但我敢说只要你观察一下项目中那些比较明显的错误，就会发现编译程序所查出的只是其中的一小部分。我还敢说，如果排除掉了程序中的所有错误那么在大部分时间内程序都会正确工作。 还记得第1章中的下面代码吗？ strCopy = memcpy(malloc(length), str, length); 该语句在多数情况下都会工作得很好，除非malloc的调用产生失败。当malloc失败时，就会给memcpy返回一个NULL指针。由于memcpy处理不了NULL指针，所以出现了错误。如果你很走运，在交付之前这个错误导致程序的瘫痪，从而暴露出来。但是如果你不走运，没有及时地发现这个错误，那某位顾客就一定会“走运”了。 编译程序查不出这种或其他类似的错误。同样，编译程序也查不出算法的错误，无法验证程序员所作的假定。或者更一般地，编译程序也查不出所传递的参数是否有效。 寻找这种错误非常艰苦，只有技术非常高的程序员或者测试者才能将它们根除并且不会引起其他的问题。 然而假如你知道应该怎样去做的话，自动寻找这种错误就变得很容易了。 两个版本的故事 让我们直接进入memcpy，看看怎样才能查出上面的错误。最初的解决办法是使memcpy对NULL指针进行检查，如果指针为NULL，就给出一条错误信息，并中止memcpy的执行。下面是这种解法对应的程序。 /* memcpy ─── 拷贝不重叠的内存块 */ void memcpy(void* pvTo, void* pvFrom, size_t size) { void* pbTo = (byte*)pvTo; void* pbFrom = (byte*)pvFrom; if(pvTo == NULL | | pvFrom == NULL) { fprintf(stderr, “Bad args in memcpy\n”); abort(); } while(size--0) *pbTo++ == *pbFrom++; return(pvTo); } 只要调用时错用了NULL指针，这个函数就会查出来。所存在的唯一问题是其中的测试代码使整个函数的大小增加了一倍，并且降低了该函数的执行速度。如果说这是“越治病越糟”，确实有理，因为它一点不实用。要解决这个问题需要利用C的预处理程序。 如果保存两个版本怎么样？一个整洁快速用于程序的交付；另一个臃肿缓慢件（因为包括了额外的检查），用于调试。这样就得同时维护同一程序的两个版本，并利用C的预处理程序有条件地包含或不包含相应的检查部分。 void memcpy(void* pvTo, void* pvFrom, size_t size) { void* pbTo = (byte*)pvTo; void* pbFrom = (byte*)pvFrom; #ifdef DEBUG if(pvTo == NULL | | pvFrom == NULL) { fprintf(stderr, “Bad args in memcpy\n”); abort(); } #endif while(size--0) *pbTo++ == *pbFrom++; return(pvTo); } 这种想法是同时维护调试和非调试（即交付）两个版本。在程序的编写过程中，编译其调试版本，利用它提供的测试部分在增加程序功能时自动地查错。在程序编完之后，编译其交付版本，封装之后交给经销商。 当然，你不会傻到直到交付的最后一刻才想到要运行打算交付的程序，但在整个的开发工程中，都应该使用程序的调试版本。正如在这一章和下一章所建，这样要求的主要原因是它可以显著地减少程序的开发时间。读者可以设想一下：如果程序中的每个函数都进行一些最低限度的错误检查，并对一些绝不应该出现的条件进行测试的活，相应的应用程序会有多么健壮。 这种方法的关键是要保证调试代码不在最终产品中出现。 利用断言进行补救 说老实话memcpy中的调试码编得非常蹩脚，且颇有点喧宾夺主的意味。因此尽管它能产生很好的结果，多数程序员也不会容忍它的存在，这就是聪明的程序员决定将所有的调试代码隐藏在断言assert中的缘故。assert是个宏，它定义在头文件assert.h中。assert虽然不过是对前面所见＃ifdef部分代码的替换，但利用这个宏，原来的代码从7行变成了1行。 void memcpy(void* pvTo, void* pvFrom, size_t size) { void* pbTo = (byte*)pvTo; void* pbFrom = (byte*)pvFrom; assert(pvTo !=