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