浅析C++ Compile-time Assertion技术
http://www.cppblog.com/nacci/archive/2005/11/07/969.aspxPosted on 2005-11-07 23:10 nacci 阅读(1354) 评论(3) 编辑 收藏 引用 所属分类: C++漫谈
你可能经常需要利用运行时断言技术，它可以方便地测试前提条件。但是，随着Metaprogramming概念的出现，编译时断言技术也已经和runtime assertion一样的普遍了。如何在编译时进行断言呢？其实，方法只有一个，就是让编译器生成一条错误信息，但是编译器生成的错误信息信息性往往有又理想。并且，即使你在一种编译上设计了一种方案，你也很难把它移植到其他的编译器上。我们通过其实现方法的改进和一个Boost中的例子，来看看如何更好的实现这种技术。
例如，你需要一个安全的类型转换机制，它只允许你把个头小的类型转换为个头大的类型。此时，就可以利用Compile-time Assertion解决这个问题。
template
<typename To, typename From>
To safe_reinterpret_cast(From from) {
assert(sizeof(To) >= sizeof(From));
return
reinterrupt_cast
};
而后，就像你使用同样的
C++
类型转换一样来使用这个
safe_reinterpret_cast
：
long
l = 255;
short
s = safe_reinterpret_cast<short>(l);
这样一来，你就可以确保只有在小
à
大的转换才是正确的，如果进行非法的转换，就会在运行时发生断言。
显然，如果能够在编译时给用户指出代码中的问题更为合适一些。如果这个转换只在程序很少被执行到的一个分支上被执行，那么当你把它移植到一个新的编译器上或平台上的时候，你就有可能忘记程序中所有不可移植的部分，例如上面提到的
reinterrupt_cast
，从而给你的程序带来不必要的
bug
。
其实，上面我们被评估的表达式是一个编译器常量，也就是说你完全有可以让编译器取代运行时代码来进行检查。解决的思路是在表达式为
true
的时候给编译器传递正确的代码，而在表达式为
false
的时候给编译器提供一个语法错误的代码，这样，当被评估的表达式为
0
的时候，编译器就会发出一个错误信号。
最简单的
compile-time assertion
解决方案是
Van Horn
在
1997
年提出的，它可以在
C
和
C++
的代码中工作，依赖的条件很简单，数组的长度不能为
0
。
#define
STATIC_CHECK(expr) { char unnamed[(expr ? 1 : 0)]; }
现在，如果你写下下面的代码：
template
<typename To, typename From>
To safe_reinterpret_cast(From from) {
STATIC_CHECK(sizeof(To) >= sizeof(From));
return
reinterpret_cast
};
… …
void
* somePointer = 0;
char
c = safe_reinterpret_cast<char>(somePointer);
如果
void*
的长度小于
char(
这个并没有在目前的
C++
标准的规定
)
，编译器就会告诉你创建了一个长度为
0
的数组。
问题是这个方法提供的错误信息并不是很说明问题。“不能创建长度为0的数组”并不能表示“char类型放不下一个指针”。这种方法很难想用户提供customized message。错误信息的来源并不是因为代码违法了程序设计的意图，而是因为破坏了某些语法规则。
更好的解决方案是依赖一个模板提供一个具有说明性的名字，这样，编译器就会在错误信息中包含这个名字了。
template
<bool> struct CompileTimeError;
template
<> struct CompileTimeError<true> {};
#define
STATIC_CHECK1(expr1) { (CompileTimeError<(expr1) != 0>()); }
CompileTimeError
带有一个非类型参数，并且只有
true
的特化版本，这样，当被评估的表达式不满足条件时，编译器就会抱怨没有
CompileTimeError
当然，这个设计仍然有很大的扩展空间。因为我们还是没有办法来订制错误消息。一个简单的办法就是在
STATIC_CHECK
中加入一个消息参数，然后让这个消息参数在错误信息中显示。这个方法也有自己的缺点，就是你必须要保证传递给
C++
的这个错误消息参数一定是合法的。于是我们可以对于上面的
CompileTimeError
做以下的改进：
template
<bool> struct CompileTimeChecker {
CompileTimeChecker(...) {};
};
template
<> struct CompileTimeChecker<false> { };
#define
STATIC_CHECK2(expr2, msg) {\
class ERROR_##msg {}; \
sizeof((CompileTimeChecker<(expr2!=0)>((ERROR_##msg()))));\
}
template
<typename To, typename From>
To safe_reinterpret_cast(From from) {
STATIC_CHECK2((sizeof(To) >= sizeof(From)),
Destination_Type_To_Narrow);
return
reinterpret_cast
};
这样，当你仍旧使用刚才的代码时：
void
* somePointer = 0;
char
c = safe_reinterpret_cast<char>(somePointer);
由于
CompileTimeChecker
cannot convert
from
'safe_reinterpret_cast::ERROR_Destination_Type_To_Narrow'
to
'CompileTimeChecker
这次的错误信息变的比较有提示性了。
现实中的应用——BOOST_STATIC_ASSERT & boost::checked_delete
BOOST_STATIC_ASSERT
在boost/static_assert.hpp中定义了一个宏BOOST_STATIC_ASSERT，用于完成编译时静态检查。其实现方式了我们的第2种方式很类似，利用了模板的特化技术
#define
BOOST_STATIC_ASSERT( B ) \
typedef ::boost::static_assert_test<\
sizeof(::boost::STATIC_ASSERTION_FAILURE< (bool)( B ) >)>\
BOOST_JOIN(boost_static_assert_typedef_, __COUNTER__)
其中：
template
<int x> struct static_assert_test{};
#define
BOOST_JOIN( X, Y ) X##Y
template
<bool x> struct STATIC_ASSERTION_FAILURE;
template
<> struct STATIC_ASSERTION_FAILURE<true> { enum { value = 1 }; };
这里，只为
true
类型进行了特化，这样，当我们尝试声明一个
STATIC_ASSERTION_FAILURE<false>
的时候就会引发编译时错误。
这样，整个宏的含义就是做了一个
typedef:
typedef
::boost::static_assert_test<evaluate condition> boost_static_assert_typedef___COUNTER__
而只有当evaluate condition为true的时候，这样的typedef才是正确的，从而实现了编译时断言（上面的代码只是msvc的实现，对不同的编译器实现略有不同，但是思想是类似的）。
例子：确保一个模板参数的类型只能是整数
template
<typename T> class only_compatible_with_integral_types {
BOOST_STATIC_ASSERT(boost::is_integral
};
之后，如果你使用下面的定义：
only_compatible_with_integral_types<double> test2;
就会引发编译错误：
use of undefined type 'boost::STATIC_ASSERTION_FAILURE
boost::checked_delete
当我们利用指针删除一个对象的时候，对象类型是否完整决定了对象是否能够被正确删除。但是，如果你用
delete
去删除一个类型并不完整的对象的指针，编译器并不会给你提供任何错误信息，但是这样做的结果却是对象的析构函数根本就没有被调用。
checked-delete
#include
class
some_class;
some_class* create() {
return (some_class*)0;
}
int
main() {
some_class* p=create();
boost::checked_delete(p2);
}
编译器就会抱怨
some_calss
是一个不完整的类型。在我们进一步去了解解决方案之前，我们先来看一个由于不完整类型带来的
memory leak
的例子：
// in deleter.h
class
to_be_deleted;
class
deleter {
public
:
void delete_it(to_be_deleted* p);
};
// in deleter.cpp
#include
"deleter.h"
void
deleter::delete_it(to_be_deleted* p) {
delete p; // !!!memory leak here
}
// in to_be_deleted.h
#include
class
to_be_deleted {
class test {
public:
test() {};
~test() { std::cout<<"I'm destructed correctly!"<
};
test* p;
public
:
to_be_deleted() { p = new test(); };
~to_be_deleted() {
delete p;
std::cout<<"I've important things to say!"<
}
};
之后用下面的测试代码：
#include
"deleter.h"
#include
"to_be_deleted.h"
int
main() {
to_be_deleted* p = new to_be_deleted();
deleter d;
d.delete_it(p);
return 0;
}
你会发现，
to_be_deleted
的析构函数并没有被调用，原因在于
deleter.cpp
中，并没有包含
to_be_deleted.h
，这样，
delete
对于齐要删除的指针一无所知，导致了析构函数并没有真正被调用。
解决的方法也很简单，利用
boost::checked_delete
进行删除。
#include
#include
"deleter.h"
void
deleter::delete_it(to_be_deleted* p) {
//delete p; // memory leak here
boost::checked_delete(p);
}
这时，编译器便会抱怨说
to_be_deleted
是未知的类型。其实
,checked_delete
的实现原理是非常简单的，只是说对于未知类型，使用
sizeof
运算符会返回
0
，而
C++
并不允许创建长度为
0
的数组。如下所示：
template
<class T> inlinevoid checked_delete(T * x)
{
// intentionally complex - simplification causes regressions
typedef
char type_must_be_complete[ sizeof(T)? 1: -1 ];
(void) sizeof(type_must_be_complete);
delete x;
}