今天拍**，拍著拍著，一不小心就撞上了靜態初始化的相依性問題。
靜態初始化的相依性問題是乙個全域性物件還未被初始化，就在另外乙個檔案中被使用。
產生靜態初始化的相依性問題的原因是，聯結器進行連線時指定的檔案初始化順序和程式設計師期望的順序不一致。
一開始還沒意識到是由於相依性造成的錯誤，只是彈出個對話方塊說afx.inl檔案的133行斷言失敗。其實這個斷言失敗前兩天已經碰到過，也是晚上加班的時候。那次是因為對靜態成員的初始化方法不正確。搜搜google，再翻翻ticpp，就解決了這個問題。但這次又冒出來相同的斷言失敗。顯然實現上還有隱藏頗深且未發現的bug。
通過檢視日至，發現是visy-quick通訊協議類的乙個型別為cstring的靜態成員變數未被初始化(即沒有分配記憶體空間，這時候cstring仍然指向null)，油品類就開始想往這個靜態成員變數內賦值了。
這時才想起來看ticpp的時候，看到有一章節就專門介紹如何處理靜態初始化的相依性。而且還提供了兩種解決方法。這個週末抽空看一下，爭取周一能把這個相依性問題給解決了。
今天仔細看了一下ticpp中eckel給出的第二種解決靜態初始化的依賴性問題的解決方法。
這個方法所依據的是函式內部定義的靜態物件在函式第一次被呼叫時初始化，且只被呼叫一次。依據這點，我們就能把乙個靜態物件放在乙個能夠返回物件引用的函式中。有誰想訪問這個靜態物件，那它必須來呼叫這個函式來獲得靜態物件。這樣就能確保靜態變數先被初始化，再被使用。
看了書中的例子，又想了一下自己的應用。一方面覺得兩邊有不小的區別，另一方面，自己的應用也比書中的離子複雜不少。最後，還是不敢在工程中貿然使用這個方法。等做了ticpp的習題後，深入理解了eckel的思想精髓，再來使用。
最後還是用了一種笨辦法，在對訪問靜態物件的類之前，對包含靜態物件的類建立例項，進行初始化。
本來這個包含靜態物件的類是負責進行通訊協議的解析和生成應答，類裡面不是靜態成員變數，就是靜態成員函式，所以，原來使用這個類是不需要建立例項的。
PHP一不小心就入坑的注意項
1 empty 用於判斷變數是否為空 0或false，變數的值如果是字串 0 時也返回true 2 isset 用於判斷變數是否被設定，即 非陣列的變數是否被賦值，陣列中指定的key是否定義且對應的value不為null 3 任意值和布林值比較時，非empty 的任意值都會被當成true處理，否則為...
一不小心，陷入TCP的效能問題
一 現象 在一次訪問請求nginx中，通常只需要幾毫秒的rt，但當請求資料達到某乙個數值時，rt明顯提高，甚至超過了300毫秒。二 問題的原因 大家都知道，tcp為了提高頻寬利用率和吞吐量，做了各種優化。比如delay ack和nagle演算法。就是這樣的一些優化使用不慎，導致陷入效能問題。接下來就...
關於初始化git不小心把東西都remove了的情況
今天幹了件蠢事，我有乙個專案包打算放到gitee上邊，別的都挺順利的初始化的，之後再push的時候發現它提示和新建的遠端倉庫不同步。我就直接pull了一下然後本地資料夾就被覆蓋成刪了好多檔案的樣子。各種配置啊還有素材啊都沒了。因為我大概是知道git有記錄的功能，所以查了好久。git checkout...