关于断言(assert) 的问题

[huabinsir]

1) assert 对Debug 版起作用， 对 Release 版不起作用.
可不可以这样理解，当assert在Debug版不出问题时，在Release 版也不出问题.

2) 以下二代段码有什么不同，请解释一下.(是不是在Release 版,有 代码二的代码量 比 代码一的代码量 大的问题)

代码一：
void *memcpy(void *pvTo, const void *pvFrom)
{
assert((pvTo != NULL) && (pvFrom != NULL)); //assert的参数为假中止, 为真继续执行

byte *pbTo = (byte *)pvTo;
.......

return pvTo;
}

代码二：
void *memcpy(void *pvTo, const void *pvFrom)
{

if ((pvTo != NULL) && (pvFrom != NULL))
{
byte *pbTo = (byte *)pvTo;
.......

return pvTo;
}
else
{
return NULL;
}

}

[nullah]

up

[laowang2]

[great3779]

4楼正解！

[qq675927952]

不懂，帮顶！

[waizqfor]

ASSERT()用只在debug版中起作用 它是测试括号内的表达式是否为真的 比如说你认为某个数不可能为零，
可以写ASSERT(x) 它在你做release时不会产生代码去检查这个值，在debug时却是有效的

[tangshuiling]

断言机制，只对debug版本有效是因为预编译指令的干涉，存在断言机制的debug版本比release版本代码量要大
断言类似于如下定义：
#ifdef_DEBUG
....断言机制有效
#else
....断言机制无效
#endif

[Jim_King_2000]

在C语言中，人们发现，程序中重复的合法性验证会导致性能的降低。因此，一般而言，当我们用C语言写程序的时候，不进行合法性验证。

但如果不进行合法性验证的话，很多逻辑错误就难以发现。我们常常会为了一个小小的低级失误而在调试器里面重复劳动好几个小时甚至几天。

因此，我们需要在不降低性能的情况下尽可能快的发现逻辑错误。

在很多时候，这些逻辑错误是我们在写程序的时候犯的。这些错误与计算机无关，纯属人为。比如传了NULL给strlen函数，或者x = a / b的时候不小心让b等于了零。这些小错误如果不幸嵌在一个有着深度循环或者递归的里面，且参数的计算十分复杂的时候，我们很难去跟踪程序崩溃的原因。assert就相当于修了一道栅栏，提醒程序员：“嘿，这里出错了。”。于是程序员能够发现是自己的程序写得不对，需要修改。

assert(b != 0);
x = a / b;

当这段代码嵌在深度循环或者递归里面，即使b的计算十分复杂，在debug版本中，我们也能很快定位到失败的环境中，并且能够查看其它变量的值。并且在release版本中，assert行自动消失，没有效率损失。

总结：
assert一般用来核实不可能发生的情况。尤其用来在debug版本检查程序员的人为错误。当人为错误被排除后，我们可以发布release版本，这时，没有任何机制来验证合法性，因此效率会得到提升。

不要用assert来验证用户输入或者函数返回值的合法性。因为用户输入是有可能非法的，函数调用也是有可能发生错误的。这些都不属于不可能发生的情况。
例如：

void *p = malloc(...);
assert(p != NULL);

在内存分配失败的情况下，malloc是有可能返回NULL的。p等于了NULL不属于不可能出现的情况，也不属于程序员的人为失误。因此在这里用assert是绝对不合适的。

[old-six-programmer]

1）一般来说，断言用在较致命的错误上

2）断言是为了发现错误而不是掩饰错误，如果release版程序崩溃，说明程序本身存在问题，提倡的做法是重新修改程序，而不是判断后的错误处理，这种处理并不能实质提升程序的健壮性，反而会增加运行成本。

3）断言用于调试，他的正确性需要通过测试来保证。正因为断言只会在debug版本起作用，因此测试就显得异常重要。经过测试后的版本，默认不会出现问题，否则说明测试不够严密，或者程序逻辑有问题。