你可能經常需要利用運行時斷言技術，它可以方便地測試前提條件。但是，隨著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
(from);
};
而后，就像你使用同樣的
C++
類型轉換一樣來使用這個
safe_reinterpret_cast
：
long
l = 255;
short
s = safe_reinterpret_cast<short>(l);
這樣一來，你就可以確保只有在小
à
大的轉換才是正確的，如果進行非法的轉換，就會在運行時發(fā)生斷言。
顯然，如果能夠在編譯時給用戶指出代碼中的問題更為合適一些。如果這個轉換只在程序很少被執(zhí)行到的一個分支上被執(zhí)行，那么當你把它移植到一個新的編譯器上或平臺上的時候，你就有可能忘記程序中所有不可移植的部分，例如上面提到的
reinterrupt_cast
，從而給你的程序帶來不必要的
bug
。
其實，上面我們被評估的表達式是一個編譯器常量，也就是說你完全有可以讓編譯器取代運行時代碼來進行檢查。解決的思路是在表達式為
true
的時候給編譯器傳遞正確的代碼，而在表達式為
false
的時候給編譯器提供一個語法錯誤的代碼，這樣，當被評估的表達式為
0
的時候，編譯器就會發(fā)出一個錯誤信號。
最簡單的
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
(from);
};
… …
void
* somePointer = 0;
char
c = safe_reinterpret_cast<char>(somePointer);
如果
void*
的長度小于
char(
這個并沒有在目前的
C++
標準的規(guī)定
)
，編譯器就會告訴你創(chuàng)建了一個長度為
0
的數組。
問題是這個方法提供的錯誤信息并不是很說明問題。“不能創(chuàng)建長度為0的數組”并不能表示“char類型放不下一個指針”。這種方法很難想用戶提供customized message。錯誤信息的來源并不是因為代碼違法了程序設計的意圖，而是因為破壞了某些語法規(guī)則。
更好的解決方案是依賴一個模板提供一個具有說明性的名字，這樣，編譯器就會在錯誤信息中包含這個名字了。
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
(from);
};
這樣，當你仍舊使用剛才的代碼時：
void
* somePointer = 0;
char
c = safe_reinterpret_cast<char>(somePointer);
由于
CompileTimeChecker
可以接受任意參數，而特化的
CompileTimeChecker
并沒有這樣的構造函數，這樣，當被評估的表達式為
0
的時候，就會出現編譯時錯誤
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，用于完成編譯時靜態(tài)檢查。其實現方式了我們的第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>
的時候就會引發(fā)編譯時錯誤。
這樣，整個宏的含義就是做了一個
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::value);
};
之后，如果你使用下面的定義：
only_compatible_with_integral_types<double> test2;
就會引發(fā)編譯錯誤：
use of undefined type 'boost::STATIC_ASSERTION_FAILURE
boost::checked_delete
當我們利用指針刪除一個對象的時候，對象類型是否完整決定了對象是否能夠被正確刪除。但是，如果你用
delete
去刪除一個類型并不完整的對象的指針，編譯器并不會給你提供任何錯誤信息，但是這樣做的結果卻是對象的析構函數根本就沒有被調用。
checked-delete
定義在
boost/checkd_delete.hpp
中，它可以保證在你摧毀一個對象的時候，必須對該對象的類型有完全的了解。先來看個例子：
#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;
}
你會發(fā)現，
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++
并不允許創(chuàng)建長度為
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;
}
/std::endl;>