Che*_*Alf 42
简而言之,不要使用它; 用<assert.h>.
C++ 11删除了"c ...."头文件的任何正式保证,不会污染全局命名空间.
它从来都不是实践中的保证,现在它甚至都不是正式保证.
因此,使用C++ 11时,使用"c ...."头部变体不再具有任何可想象的优势,同时存在明显的缺点,即与一个编译器和该编译器的版本一起工作良好的代码,由于例如全局命名空间中的名称冲突或不同的重载选择,无法使用其他编译器或版本进行编译.
因此,虽然cassert在C++ 03中没有任何意义(你不能在命名空间中放置一个宏),但它在C++ 11中完全没有意义 - 即使是一般方案的一个特例.
附录,2013年12月22日:
该标准根据<cX>标头定义每个C++ C标头 <Xh>标头,而该标头又根据相应的C库标头定义.
C++11§D.5/ 2:
"每个C头,每个都有一个表单的名称
name.h,就好像每个由相应的cname头放在标准库名称空间中的名称放在全局名称空间范围内."
C++11§D.5/ 3(非规范性示例):
"标题
<cstdlib>确实在命名空间中提供了声明和定义std.它还可以在全局命名空间中提供这些名称.标题<stdlib.h>肯定在全局命名空间中提供相同的声明和定义,就像在C标准中一样.它也可以在命名空间中提供这些名称std."
Stack Overflow用户CR的评论让我意识到某些版本的g ++,例如MinGW g ++ 4.7.2,在标题方面非常不标准<X.h>,缺少例如sinC++标准所要求的重载:
我已经知道MinGW g ++ 4.7.2也完全缺乏诸如此类的功能swprintf,并且它在纯C++库中具有同样的缺点,例如缺少C++ 11 std::to_string.但是,缺少C函数重载的信息对我来说是新的.
在实践中,g ++缺乏重载意味着
无视g ++问题,或
避免使用缺少的g ++重载,
例如仅使用double sin( double ),或
使用std命名空间重载
(然后需要包含<cmath>以保证它们与g ++的存在).
为了使用g ++ std命名空间重载不合格,一种实用的方法是为此编译器定义头包装器.我用这种方法来解决g ++的缺点.对printf家庭.正如戴维·惠勒曾经说过的那样,"计算机科学中的所有问题都可以通过另一层间接来解决"......
然后可以安排一些事情,以便使用g ++缺少重载的标准代码也可以用g ++编译.这会将编译器调整为标准,并使用固定数量的代码.