你可能經(jīng)常需要利用運(yùn)行時斷言技術(shù)，它可以方便地測試前提條件。但是，隨著Metaprogramming概念的出現(xiàn)，編譯時斷言技術(shù)也已經(jīng)和runtime assertion一樣的普遍了。如何在編譯時進(jìn)行斷言呢？其實，方法只有一個，就是讓編譯器生成一條錯誤信息，但是編譯器生成的錯誤信息信息性往往有又理想。并且，即使你在一種編譯上設(shè)計了一種方案，你也很難把它移植到其他的編譯器上。我們通過其實現(xiàn)方法的改進(jìn)和一個Boost中的例子，來看看如何更好的實現(xiàn)這種技術(shù)。
例如，你需要一個安全的類型轉(zhuǎn)換機(jī)制，它只允許你把個頭小的類型轉(zhuǎn)換為個頭大的類型。此時，就可以利用Compile-time Assertion解決這個問題。
template <typename To, typename From>
To safe_reinterpret_cast(From from) {
assert(sizeof(To) >= sizeof(From));
return reinterrupt_cast (from);
};
而后，就像你使用同樣的 C++ 類型轉(zhuǎn)換一樣來使用這個 safe_reinterpret_cast ：
long l = 255;
short s = safe_reinterpret_cast<short>(l);
這樣一來，你就可以確保只有在小 à 大的轉(zhuǎn)換才是正確的，如果進(jìn)行非法的轉(zhuǎn)換，就會在運(yùn)行時發(fā)生斷言。
顯然，如果能夠在編譯時給用戶指出代碼中的問題更為合適一些。如果這個轉(zhuǎn)換只在程序很少被執(zhí)行到的一個分支上被執(zhí)行，那么當(dāng)你把它移植到一個新的編譯器上或平臺上的時候，你就有可能忘記程序中所有不可移植的部分，例如上面提到的 reinterrupt_cast ，從而給你的程序帶來不必要的 bug 。
其實，上面我們被評估的表達(dá)式是一個編譯器常量，也就是說你完全有可以讓編譯器取代運(yùn)行時代碼來進(jìn)行檢查。解決的思路是在表達(dá)式為 true 的時候給編譯器傳遞正確的代碼，而在表達(dá)式為 false 的時候給編譯器提供一個語法錯誤的代碼，這樣，當(dāng)被評估的表達(dá)式為 0 的時候，編譯器就會發(fā)出一個錯誤信號。
最簡單的 compile-time assertion 解決方案是 Van Horn 在 1997 年提出的，它可以在 C 和 C++ 的代碼中工作，依賴的條件很簡單，數(shù)組的長度不能為 0 。
#define STATIC_CHECK(expr) { char unnamed[(expr ? 1 : 0)]; }
現(xiàn)在，如果你寫下下面的代碼：
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++ 標(biāo)準(zhǔn)的規(guī)定 ) ，編譯器就會告訴你創(chuàng)建了一個長度為 0 的數(shù)組。
問題是這個方法提供的錯誤信息并不是很說明問題。“不能創(chuàng)建長度為0的數(shù)組”并不能表示“char類型放不下一個指針”。這種方法很難想用戶提供customized message。錯誤信息的來源并不是因為代碼違法了程序設(shè)計的意圖，而是因為破壞了某些語法規(guī)則。
更好的解決方案是依賴一個模板提供一個具有說明性的名字，這樣，編譯器就會在錯誤信息中包含這個名字了。
template <bool> struct CompileTimeError;
template <> struct CompileTimeError<true> {};
#define STATIC_CHECK1(expr1) { (CompileTimeError<(expr1) != 0>()); }
CompileTimeError 帶有一個非類型參數(shù)，并且只有 true 的特化版本，這樣，當(dāng)被評估的表達(dá)式不滿足條件時，編譯器就會抱怨沒有 CompileTimeError 的特化版本，這個比剛才的錯誤多多少少要好一些。
當(dāng)然，這個設(shè)計仍然有很大的擴(kuò)展空間。因為我們還是沒有辦法來訂制錯誤消息。一個簡單的辦法就是在 STATIC_CHECK 中加入一個消息參數(shù)，然后讓這個消息參數(shù)在錯誤信息中顯示。這個方法也有自己的缺點，就是你必須要保證傳遞給 C++ 的這個錯誤消息參數(shù)一定是合法的。于是我們可以對于上面的 CompileTimeError 做以下的改進(jìn)：
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);
};
這樣，當(dāng)你仍舊使用剛才的代碼時：
void * somePointer = 0;
char c = safe_reinterpret_cast<char>(somePointer);
由于 CompileTimeChecker 可以接受任意參數(shù)，而特化的 CompileTimeChecker 并沒有這樣的構(gòu)造函數(shù)，這樣，當(dāng)被評估的表達(dá)式為 0 的時候，就會出現(xiàn)編譯時錯誤
cannot convert
from
'safe_reinterpret_cast::ERROR_Destination_Type_To_Narrow'
to
'CompileTimeChecker'
這次的錯誤信息變的比較有提示性了。
現(xiàn)實中的應(yīng)用——BOOST_STATIC_ASSERT & boost::checked_delete
BOOST_STATIC_ASSERT
在boost/static_assert.hpp中定義了一個宏BOOST_STATIC_ASSERT，用于完成編譯時靜態(tài)檢查。其實現(xiàn)方式了我們的第2種方式很類似，利用了模板的特化技術(shù)
#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 類型進(jìn)行了特化，這樣，當(dāng)我們嘗試聲明一個 STATIC_ASSERTION_FAILURE<false> 的時候就會引發(fā)編譯時錯誤。
這樣，整個宏的含義就是做了一個 typedef:
typedef ::boost::static_assert_test<evaluate condition> boost_static_assert_typedef___COUNTER__
而只有當(dāng)evaluate condition為true的時候，這樣的typedef才是正確的，從而實現(xiàn)了編譯時斷言（上面的代碼只是msvc的實現(xiàn)，對不同的編譯器實現(xiàn)略有不同，但是思想是類似的）。
例子：確保一個模板參數(shù)的類型只能是整數(shù)
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
當(dāng)我們利用指針刪除一個對象的時候，對象類型是否完整決定了對象是否能夠被正確刪除。但是，如果你用 delete 去刪除一個類型并不完整的對象的指針，編譯器并不會給你提供任何錯誤信息，但是這樣做的結(jié)果卻是對象的析構(gòu)函數(shù)根本就沒有被調(diào)用。
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 是一個不完整的類型。在我們進(jìn)一步去了解解決方案之前，我們先來看一個由于不完整類型帶來的 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ā)現(xiàn)， to_be_deleted 的析構(gòu)函數(shù)并沒有被調(diào)用，原因在于 deleter.cpp 中，并沒有包含 to_be_deleted.h ，這樣， delete 對于齊要刪除的指針一無所知，導(dǎo)致了析構(gòu)函數(shù)并沒有真正被調(diào)用。
解決的方法也很簡單，利用 boost::checked_delete 進(jìn)行刪除。
#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 的實現(xiàn)原理是非常簡單的，只是說對于未知類型，使用 sizeof 運(yùn)算符會返回 0 ，而 C++ 并不允許創(chuàng)建長度為 0 的數(shù)組。如下所示：
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;
}