在什么情况下我们应该包含 cassert ?
答案 0 :(得分:41)
简而言之,不要使用它;使用<assert.h>
。
C ++ 11删除了“c ....”标头的任何正式保证,不会污染全局命名空间。
这绝不是实践中的保证,现在它甚至都不是正式保证。
因此,使用C ++ 11时,使用“c ....”头部变体不再具有任何可想象的优势,同时存在明显的缺点,即代码适用于一个编译器和版本的代码由于例如,编译器可能无法使用其他编译器或版本进行编译在全局命名空间中命名冲突或不同的重载选择。
所以,虽然cassert
在C ++ 03中毫无意义(你不能把宏放在命名空间中),但它完全没有意义 - 即使是一般方案的一个特例 - 在C ++ 11
附录,2013年12月22日:
标准定义了每个C ++ C标头&lt; X.h&gt;根据&lt; cX&gt;的标题header,它依次是根据相应的C库头定义的。
C ++11§D.5/ 2 :
“每个C标头,每个标头都有一个
name.h
形式的名称,就好像每个名称放在标准库命名空间中的相应 cname 标头放在全局命名空间范围。“
C ++11§D.5/ 3 (非规范性示例):
“标题
<cstdlib>
肯定在名称空间std
中提供其声明和定义。它还可以在全局命名空间中提供这些名称。标头<stdlib.h>
确实在全局命名空间中提供相同的声明和定义,就像在C标准中一样。它还可以在命名空间std
中提供这些名称。“
Stack Overflow用户C.R.的评论让我意识到g ++的某些版本,例如MinGW g ++ 4.7.2,相对于{{1}非常非标准标题,缺少例如的重载{+ 1}} C ++标准要求:
我已经知道MinGW g ++ 4.7.2也完全缺少诸如<X.h>
之类的功能,并且它在纯C ++库中具有同样的缺点,例如缺少C ++ 11 sin
。但是,缺少C函数重载的信息对我来说是新的。
实际上,缺少g ++的重载意味着
忽略g ++问题,或
避免使用缺少的g ++重载,
例如仅使用swprintf
或
使用std::to_string
命名空间重载
(然后需要包括double sin( double )
以保证他们的存在与g ++)。
为了使用g ++ std
命名空间重载不合格,一种实用的方法是为此编译器定义 headers wrappers 。我用这种方法来解决g ++的缺点。到<cmath>
家庭。正如大卫·惠勒曾经说过的那样,“计算机科学中的所有问题都可以通过另一层间接来解决”......
然后可以安排一些事情,以便使用g ++缺少重载的标准代码也可以用g ++编译。这会将编译器调整为标准,并使用固定数量的代码。
答案 1 :(得分:8)
就像任何其他头文件一样,当您使用该头文件中声明的内容时,#include <cassert>
,例如assert()
。
答案 2 :(得分:0)
查看易于访问的reference
#include <iostream>
// uncomment to disable assert()
// #define NDEBUG
#include <cassert>
int main()
{
assert(2+2==4);
std::cout << "Execution continues past the first assert\n";
assert(2+2==5);
std::cout << "Execution continues past the second assert\n";
}
答案 3 :(得分:0)
assert.h定义了一个可用作标准调试工具的宏函数。