在什么情况下，我们需要包含<cassert>？
在什么情况下，我们应该包括cassert ？
总之，不要使用它; 使用<assert.h> 。
C ++ 11删除了不污染全局名称空间的“c ….”标头的任何forms保证。
这不是一个实践的保证，现在它甚至不是一个正式的保证。
因此，在C ++ 11中，使用“c ….”头variables不再有任何可以想象的优点，但是有一个独特而明显的缺点，那就是编译器和编译器版本可以正常工作的代码可能由于例如全局命名空间中的名称冲突或不同的重载select而无法与另一个编译器或版本进行编译。
所以，虽然在C ++ 03中cassert非常没有意义（你不能把一个macros放在一个名字空间中），但在C ++ 11中，这是完全没有意义的 – 即使是一个通用的scheme的特殊情况。
附录 ，2013年12月22日：
该标准以<cX>标题的forms定义了每个C ++ C标题 <Xh>标题，而标题则依据相应的C库标题定义。
C ++ 11§D.5/ 2 ：
“每个C头，每个头都有一个
name.hforms的name.h，就好像每个名字放在标准库名字空间中的相应的cname头被放在全局名字空间的范围内。
C ++ 11§D.5/ 3 （非规范示例）：
头文件
<cstdlib>确实在命名空间std提供了它的声明和定义。 它也可能在全局命名空间中提供这些名字。 头文件<stdlib.h>确实在全局命名空间中提供了相同的声明和定义，就像C标准一样。 它也可能在命名空间std提供这些名字。“
堆栈溢出用户CR的评论让我意识到，g ++的一些版本，比如MinGW g ++ 4.7.2，对于<Xh>头文件来说是非常不标准的 ，没有C ++标准所要求的sin的重载：
我已经知道MinGW g ++ 4.7.2也完全没有swprintf这样的函数，而且在纯C ++库中缺less如C ++ 11 std::to_string这样的缺点。 然而，关于它缺lessC函数重载的信息对我来说是新的。
在实践中，缺lessg ++意味着超负荷
-
忽略g ++的问题，或者
-
避免使用缺less的g ++重载，
例如只使用double sin( double )，或 -
使用
std命名空间重载
（然后需要包含<cmath>来保证它们在g ++中的存在）。
为了使用g ++ std命名空间重载不合格，一个实际的方法是为这个编译器定义头文件包装器。 我用这种方法来解决g ++的缺点。 到printf家庭。 正如戴维·惠勒（David Wheeler）曾经说过的，“计算机科学中的所有问题都可以通过另一个层面来解决”。
然后可以安排事物，以便使用g ++的缺less重载的标准代码也可以用g ++编译。 这将编译器调整为标准，具有固定数量的代码。
就像任何其他的头文件一样，当你使用在头文件中声明的东西，比如assert() ， #include <cassert> 。
看到一个容易访问的参考
#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"; }
assert.h定义了一个可以用作标准debugging工具的macrosfunction。
