Sunday, January 6, 2008

ASSERT()和assert()的区别是什么?

ASSERT()是一个调试程序时经常使用的宏,在程序运行时它计算括号内的表达式,如果表达式为FALSE (0), 程序将报告错误,并终止执行。如果表达式不为0,则继续执行后面的语句。这个宏通常原来判断程序中是否出现了明显非法的数据,如果出现了终止程序以免导致严重后果,同时也便于查找错误。例如,变量n在程序中不应该为0,如果为0可能导致错误,你可以这样写程序:
......
ASSERT( n != 0);
k = 10/ n;
......

ASSERT只有在Debug版本中才有效,如果编译为Release版本则被忽略。


assert()的功能类似,它是ANSI C标准中规定的函数,它与ASSERT的一个重要区别是可以用在Release版本中。
要使assert失效,只有在包含assert头文件(assert.h)的语句前定义NDEBUG宏或在编译器参数中添加-DNDEBUG参数

assert

当构造一个应用程序的时候,应该始终记住:应该让程序在出现bug或非预期的错误的时候,应该让程序尽可能早地突然死亡。这样做可以帮助你在开发——测试循环中尽早地发现错误。不导致突然死亡的错误将很难被发现;它们通常会被忽略,直到程序在客户系统中运行以后才被注意到。

检查非预期状态的最简单的方式是通过标准C库的assert宏。这个宏的参数是一个布尔表达式(Boolean expression)。当表达式的值为假的时候,assert会输出源文件名、出错行数和表达式的字面内容,然后导致程序退出。Assert宏可用于大量程序内部需要一致性检查的场合。例如,可以用assert检查程序参数的合法性、检查函数(或C++中的类方法)的前提条件和最终状态(postcondition)、检查非预期的函数返回值,等等。

每次使用assert宏,不仅可以作为一项运行期的检查,还可以被当作是嵌入代码中的文档,用于指明程序的行为。如果你的程序中包含了assert( condition ),它就是在告诉阅读代码的人:condition在这里应该始终成立;否则很可能是程序中的bug。

对于效率至上的代码,assert这样的运行时检查可能引入严重的效率损失。在这种情况下,你可以定义NDEBUG宏并重新编译源码(可以通过在编译器参数中添加 –DNDEBUG参数做到)。在这种情况下,assert宏的内容将被预处理器清除掉。应该只在当效率必须优先考虑的情况下,对包含效率至上的代码的文件设置NDEBUG宏进行编译。

因为assert可能被预处理过程清除,当使用这个宏的时候必须确信条件表达式不存在副作用。特别的,不应该在assert的条件表达式中使用这些语句:函数调用、对变量赋值、使用修改变量的操作符(如 ++ 等)。

例如,假设你在一个循环中重复调用函数do_something。这个函数在成功的情况下返回0,失败则返回非0值。但是你完全不期望它在程序中出现失败的情况。你可能会想这样写:

for (i = 0; i < 100; ++i) assert (do_something () == 0);

不过,你可能发现这个运行时检查引入了不可承受的性能损失,并因此决定稍候指定NDEBUG以禁用运行时检测。这样做的结果是整个对assert的调用会被完全删除,也就是说,assert宏的条件表达式将永远不会被执行,do_something一次也不会被调用。因此,这样写才是正确的: for (i = 0; i < 100; ++i) { int status = do_something (); assert (status == 0); }

另外一个需要记住的是,不应该使用assert去检测不合法的用户输入。用户即使在输入不合适的信息后也不希望看到程序仅在输出一些含义模糊的错误信息后崩溃。你应该检查用户的非法输入并向用户返回可以理解的错误信息。只当进行程序内部的运行时检查时才应使用assert宏。 一些建议使用assert宏的地方:

检查函数参数的合法性,例如判断是否为NULL指针。由 { assert (pointer != NULL)} 得到的错误输出 Assertion ‘pointer != ((void *)0)’ failed. 与当程序因对NULL指针解引用得到的错误信息 Segmentation fault (core dumped) 相比而言要清晰得多。
检查函数参数的值。例如,当一个函数的foo参数必须为正数的时候我们可以在函数开始处进行这样的检查: assert (foo > 0); 这会帮助你发现错误的调用;同时它很清楚地告诉了读代码的人:这个函数对参数的值有特殊的要求。

不要就此退缩;在你的程序中适当地时候使用assert宏吧。

0 comments: