(五)静态断言(下),static_assert

时间:2021-07-08 09:08:40

二、静态断言与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一样,其他都不变。

我们编译一下:

(五)静态断言(下),static_assert

很明显,它不会出错。

我们来执行一下:

(五)静态断言(下),static_assert

这时候,我们的断言才能检查出错误。

在一些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);
}

(五)静态断言(下),static_assert

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

这样的信息就非常清楚,也非常有利于我们排错。

而由于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 机制

希望大家能够正确运用它们。

感谢您的阅读,生活愉快~