1.符號修飾與函式簽名誕生的背景和條件:
20世紀70年代，編譯器編譯源**產生目標檔案時，符號與相應的變數和函式的名字是一樣的.後來unix平台和ｃ語言
發明時，已經存在了相當多的使用彙編編寫的庫和目標檔案.這樣問題就產生了，乙個ｃ程式要使用這些庫的話，ｃ語言
中不可以使用這些庫中定義的函式和變數的名字作為符號名，否則將會跟現有的目標檔案衝突.
為了防止類似的符號名衝突，unix下的ｃ語言就規定,ｃ語言源**中的所有全域性變數和函式經過編譯後，相對應的符號名
前加上下劃線"_".而fortran語言的源**經過編譯以後，所有的符號前後都加上"_".
這種簡單而原始的方法的確能夠暫時減少多種語言目標檔案之間的符號衝突的概率，但是沒有從根本上去解決符號衝突的問題.
a. 對不同語言源**編譯後生成的目標檔案中新增上不同的符號約束，但是同一種語言的符號衝突問題還是沒有解決.
b. 由於模組是協同開發的原因，導致出現的符號衝突概率更大. 如果想要減少衝突，那麼就要制定相當複雜和繁瑣的編碼規範.
修飾和函式簽名.至於其中的相關細節，我想這些沒必要討論，其原理是很簡單的：
使用名稱修飾和函式簽名就是為了使避免產生符號衝突.使用一定的機制使源**中的符號在生成的目標檔案中能夠保持
HKMG來龍去脈
1.為什麼要high k。隨著cmos電路線寬的不斷縮小，電晶體的乙個關鍵指標 柵氧厚度也要不斷縮小。以intel為例90nm時代實際應用的柵氧厚度最低達到了1.2nm，45nm時代更是需要低至1nm以下的柵氧厚度。不過柵氧厚度是不能無限縮小的，因為薄到2nm以下的sio2層不再是理想的絕緣體，會出...
keepalive的來龍去脈
今天有同事反應在效能測試環境cpu load 很高有500 多，我的分析過程是這樣的，先用visualvm 連上去觀察了下，發現請求都卡在channelsocket 的read 上面。這一步是mod jk 的 並未真正進入應用 所以懷疑是apache 和jboss 之間出現了為題，為了印證這個猜測，...
訊息的來龍去脈
上面敘述的過程就是訊息觸發演算法的過程，又稱訊息驅動。這樣乙個過程對於想入門windows開發的人來說門檻太高，對於大型的windows程式來說開發與維護成本也不低。隨著微軟物件導向開發平台日趨成熟，微軟把訊息機制封裝成了更容易讓人理解的事件模型。事件模型隱藏了訊息機制的很多細節，讓程式的開發變得簡...