二、静态断言与static_assert
通过上一篇,我们可以看到,断言assert宏只有在程序运行的时候才能起作用。而#error值在编译器预处理时才能起作用。
有时候,我们希望在编译时候能做一些断言。
看下面这个例子:
#include<iostream>
#include<cassert>
using namespace std;
//枚举编译器对各种特性的支持,每个枚举值占一位
enum FeatureSupports
{ //为了阅读方便,以下注释后两位
C99 = 0x0001, // 0000 0001
ExiInt = 0x0002, // 0000 0010
SAssert = 0x0004, // 0000 0100
NoExcept = 0x0008, // 0000 1000
SMAX = 0x0010, // 0001 0000
};
//一个编译器类型,包括名称、特性支持等
struct Compiler
{
const char* name;
int spp; //使用FeatureSupports 枚举
}; int main()
{
//检查枚举值是否完备
assert((SMAX - ) == (C99 | ExiInt | SAssert | NoExcept)); //检验设置的枚举是否有重位 Compiler a = { "abc",(C99 | SAssert) };
//....
if (a.spp&C99) //结果应该是C99
{
cout << "if判定中的结果为" << (a.spp&C99) << endl;
}
}
整个程序执行结果为 if判定中的结果为1
表明不会触发断言,说明定义的枚举没有冲突,并且执行情况与我们预期的一样,可能没看懂这个程序的意图,可以继续往下看。
上述所示的是C代码中常见的“按位存储属性”的例子。
在该例中,我们编写了一个枚举类型FeatureSupports,用于列举编译器对各种特性的支持。
而结构体Compiler 则包含了一个int 类型成员spp。由于各种特性都具有“支持”和“不支持”两种状态,所以为了节省存储空间,我们让每个FeatureSupports 的枚举值占据一个特定的比特位置,并在使用时通过“或”运算压缩地存储在spp中。在使用的时候,则可以通过检查spp的某位来判断编译器对特性是否支持。
比如:如果spp的值为5(即0000 0000 0000 0101),说明它支持C99和SAssert两种特性,因为spp的值是通过枚举量或运算得来的。
但是,有的时候枚举值会非常多,而且还会在代码维护中不断增加。那么代码编写者必须想出办法对这些枚举进行校验,比如查验一下是否有重位等。在本例中程序员的做法是使用一个“最大枚举”SMAX,并通过比较SMAX-1与所有其他枚举的或运算值来验证是否有枚举值重位。
可以想象,如果SAssert被误定义为0x0001,表达式(SAssert-1)==(C99 | ExtInt | SAssert | NoExcept)将不再成立。
在本例中,我们使用了断言assert。但assert是一个运行时的断言,这意味着不运行程序我们将无法得知是否有枚举重位。在一些情况下,这是不可接受的,因为可能单次运行代码并不会调用到assert相关的代码路径。因此,这样的校验最好是在编译时期就能完成。
相关的测试:
如果有ExiInt的值改成和C99一样,其他都不变。
我们编译一下:
很明显,它不会出错。
我们来执行一下:
这时候,我们的断言才能检查出错误。
在一些C++的模板的编写中,我们可能也会遇到相同的情况,比如下面这个例子:
#include<cassert>
#include<cstring>
using namespace std; template <typename T,typename U>
void bit_copy(T& a, U& b)
{
assert(sizeof b == sizeof a);
memcpy(&a,&b,sizeof b)
} int main()
{
int a = 0x2468;
double b;
bit_copy(a, b);
}
上述代码中assert是要保证a和b两种类型的长度一致,这样bit_copy才能够保证赋值操作不会遇到越界等问题。这里我们还是使用assert的这样的运行时断言,但如果bit_copy不被调用,我们将无法触发该断言。实际上,正确产生断言的时机应该在模板实例化的时候,即编译时期。
(个人感觉这个例子不是很好,但是是这么个道理哈)
上述代码同样编译通过,运行出错。不再测试。
上述两个问题的解决方案是进行编译时期的断言,,即所谓的“静态断言”。事实上,利用该语言规则实现静态断言的讨论非常多,比较典型的实现是开源库Boost内置的BOOST_STATIC_ASSERT断言机制(利用sizeof操作符)。我们可以利用“除0"会导致编译器报错这个特性来实现静态断言。
#define assert_static(e) \
do { \
enum{assert_static__ = /(e)}; \
} while()
在理解这段代码的时候,可以忽略do while循环以及enum这些语法上的技巧。真正起作用的只是1/(e)。
#include<iostream> //不需要
#include<cmath> //不需要
#include<cstring>
using namespace std; #define assert_static(e) \
do { \
enum{ assert_static__ = /(e) }; \
} while() template <typename T,typename U>
void bit_copy(T& a, U& b)
{
assert_static(sizeof(b) == sizeof(a)); //如果改为!=则不会出错
memcpy(&a, &b, sizeof b);
} int main()
{
int a = 0x2468;
double b = 2.1;
bit_copy(a, b);
}
14行在编译的时候会报错。
如果我们把14行改为 != 号则会通过编译,执行也没有问题,说明该错误确实是assert在编译时候发出的错误
其实理解起来没什么困难,因为宏定义就要在编译的时候就会执行,所以,通过这个巧妙的方式正确打开我们 静态断言——static_assert !
在C++11标准中,引入了static_assert 断言来解决之前的问题。
static_assert用起来非常简单,它接受两个参数,一个是断言表达式,这个表达式通常返回一个bool值,另一个是警告信息,它通常是一段字符串。
我们可以用static_assert 来替代上述代码的14行,如下:
static_assert(sizeof(b) == sizeof(a), "the parameters of bit_copy must have same width");
报错信息如下:(编译时期)
这样的信息就非常清楚,也非常有利于我们排错。
而由于static_assert 是编译时期的断言,其使用范围不像assert一样受到限制。
在通常情况下,static_assert 可以用于任何名字空间,例如:
static_assert(sizeof(int) == , "This 64-bit machine should follow this!");
int main() { }
就这两行就可以,不需要其他的头文件或其他代码,第一行就可以执行。
在C++中,函数则不可能像上述代码中的static_assert 这样独立于任何调用之外运行。
因此,将static_assert 写在函数体外通常是较好的选择,这让代码阅读者可以较容易发现static_assert 为断言而非用户定义的函数。
而反过来讲,必须注意的是static_assert 的断言表达式的结果必须是在编译时期可以计算的表达式,即必须是常量表达式。
如果使用了变量,就会导致错误。例如:
int positive(const int& n)
{
static_assert(n > , "value must > 0");
}
上述代码使用了参数变量n(虽然是一个const参数),因而无法通过编译。对于此例,如果需要的只是运行时的检查(为什么这么说呢,变量n一定是运行的时候才能通过传递参数得知,所以,从代码的意图上看可能需要的只是运行时的检查),那么还是应该使用assert 宏。
三、总结
到这里,我们的断言机制基本上就完了,不同的机制对应不同的类型,不同的时期。
运行时期的 assert 宏
编译时期的 static_assert 静态断言
预处理时期的 #if 和 #error 机制
希望大家能够正确运用它们。
感谢您的阅读,生活愉快~