在前面對glog分別做了兩次學習，請看C++的開源跨平台日志庫glog學習研究(一)、C++的開源跨平台日志庫glog學習研究(二)--宏的使用，這篇再做個掃尾工作，算是基本完成了。 編譯期斷言 動態斷言在調試過程中是一個很重要的手段，而且我們使用的也比較多。相應的，靜態斷言，也即是編譯期斷言隨著模板編程、元編程的發展，也表現出了動態斷言所沒有的優勢：在編譯期完成斷言檢查，而不是等到運行時！ 比如在glog的源碼中，有如下代碼（logging.h line 908）： 1 template <bool> 2 struct CompileAssert { 3 }; 4 5 #define GOOGLE_GLOG_COMPILE_ASSERT(expr, msg) \ 6 typedef google::glog_internal_namespace_::CompileAssert<(bool(expr))> msg[bool(expr) ? 1 : -1] 先給出一個簡單的測試用例： 1 GOOGLE_GLOG_COMPILE_ASSERT(1, must_be_true1); //ok 2 GOOGLE_GLOG_COMPILE_ASSERT(-1>0,must_be_true2); //error 上面這兩句測試代碼中第二句是通不過的，在Windows下visual studio報錯： error C2118: negative subscript 在linux下報錯： 錯誤：數組‘must_be_true’的大小為負 這個錯誤很明顯，也即在GOOGLE_GLOG_COMPILE_ASSERT宏中，如果第一個參數expr為true，那麼根據第二個參數msg就可以創建一個含一個CompileAssert對象的數組： google::glog_internal_namespace_::CompileAssert<1> msg[1]; 否則，一旦第一個參數expr為false，那麼就是： google::glog_internal_namespace_::CompileAssert<0> msg[-1]; 好吧，因為數組大小在C++中是不能為負的！這樣就保證了宏能夠在編譯期完成檢查。 編譯期檢查、編譯器斷言是很有用的一個功能，尤其是在C++的模板編程、元編程中，其作用不可小觑。當然，也有一定的缺點，比如對於動態變化的值，卻無法使用編譯期斷言而只能使用動態斷言： 1 void test(int i) 2 { 3 assert(i>0); //ok 4 GOOGLE_GLOG_COMPILE_ASSERT(i>0, must_be_true); //error 5 } 在Windows下和linux下分別報錯如下： VisualStudio： error C2975: 'unnamed-parameter' : invalid template argument for 'google::glog_internal_namespace_::CompileAssert', expected compile-time constant expression GCC：錯誤：‘i’不能出現在常量表達式中 名字重整解析 在glog的源碼文件目錄中，有兩個文件：demangle.h和demangle.cc。這兩個文件只實現了一個對外接口： bool Demangle(const char *mangled, char *out, int out_size); 且在整個項目中並沒有使用，但其實是很有用的一個功能，為什麼這麼說？因為這是用於實現解析C++中名字重整後的函數原型。比如對於一個經過編譯器名字重整後為_Z1fi的函數，經過解析後得到其原型是f(int)，同理，詳細請看我之前寫的一篇文章：C++中的名字重整技術。 字符串的模糊匹配 在vlog_is_on.cc的line 69行有一個SafeFNMatch_的函數實現，該函數可以用來實現簡單的字符串模糊匹配功能，這裡就不再多說了，請參考我之前寫的一篇文章：C++實現的字符串模糊匹配。 代碼規范 一個小小的glog庫，從代碼上也能看出Google的代碼規范，比如頭文件引用一般次序是C庫、C++庫、其他庫的.h、項目內的.h等，請看Google完整的C++代碼規范：Google的C++編碼規范中文版。這裡就不再介紹了。
