在前面對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++編碼規范中文版。這里就不再介紹了。