就給我去死!       我發現我的心情很難被影響，在高興的時候一些不好的小事我會直接無視，在不爽的時候也很難挽回低落的心情。所以壞處就是，雖然心情不容易變壞，但是一旦變壞，那就好幾天都好轉不了，不管是多么小的事。
      這大概就是傳說中的拿得起放不下。
      嗯。今天一天的心情就被區區小事給毀了。不知道明天會不會忘掉。
      多半還會繼續不爽。埃，幾天就畢業了，大家作鳥獸散，心中本應有的是那種既高興又傷感，充滿了回憶和憧憬的情感，但是現在只剩下一肚子的


                  怨念。

在本機上調試Linux內核實在是慘烈，各種錯誤都能出來：
1。鍵盤無反應
2。鼠標無反應
3。鍵盤鼠標一起無反應
4。屏幕突然黑掉
5。直接重啟動
6。屏幕黑掉，數秒后出現一幅銀灰色圖片，數秒后重啟動

7。進程無法啟動
8。不能切換到root
于是我一天重啟動40+次，囧      可以很明顯的感覺到，在不斷的努力下，校內的本屆，以及下幾屆的技術圈，漸漸開始接受boost， 接觸boost，甚至asio等等，boost以從未有過的高速，走進了人們的視野。
    看到這一切，很欣慰，也很有成就感。      摘要: 平臺 i386 ， win32 ， msvc 2003   代碼簡單介紹：   調度算法：輪轉法。。，可修改   內存模型：每個線程擁有各自獨立的堆棧。啟動線程的時候，切換到對應的堆棧再啟動，使得線程之間的堆棧互不干擾   調度方式：線程調用 schedule 函數， schedule 用 setjmp 保存當前堆棧，選擇一個...  閱讀全文 這家伙的書寫的太牛了，而且太有創意了 下面是腮邊打網的東西
1。學了一點點法語（處于會說但聽不懂的階段）
2。深入了解了佛教等幾大宗教，認真學習了佛教的教義（不過仍然沒信教）
3。對西方古典音樂有了系統的學習
4。終于開始用linux了，我真土

下面是技術：
1。重新看了libtorrent的代碼
2。被迫研究Windows，ReactOS，wine和linux的源代碼，挖得有點感覺了
3。寫了一堆范型的概念實現（typeof，multibyte什么的）
4。摸了摸boost.MPL，寫了一個靜態狀態機（結果代碼不小心被誤刪了。。。）
5。用asio寫了些東西，不過都是很土的程序

好像沒做什么事情唉


下面是階段性的
1。保研了
2。實習了
3。寫書了

說到 C/C++ 的資源管理，人人都會頭痛半天。自從 C++0x （就是 C++09 了）標準漏出風聲之后， C++ 標準是否會引入自動垃圾回收機制就成為了眾多 C++ 愛好者談論的話題。但是實際上，在 C++ 標準的探索上，垃圾回收一直處在一個十分低下的地位。造成其這一處境的原因很多，也很復雜。我們來看看站在 C++ 程序員的角度上看，資源管理機制現在所面臨的局勢。

從系統結構上來講， C/C++ 支持 3 種內存管理方式，基于棧的自動管理，基于堆的動態管理，和基于全局區的靜態管理。由于 RAII 的理念，對于 C++ 來說，內存管理和其他資源管理本質上沒有區別。因此對于資源而言，也就自然的擁有這樣 3 種管理方式。

首先簡要的介紹一下 RAII 。 RAII 的全稱是 Resource Acquisition Is initialization 。這個思想的基本手法是對于一種想要使用的資源，為其書寫一個 guard 類，在該類的構造函數里進行資源的請求，在析構函數里進行資源的釋放。例如假設我們想管理一個互斥鎖，可能的方式是：

struct  lock_guard
{
        lock_guard() { lock ();}
         ~ lock_guard() {unlock();}
} ;

     此后，對這個對象使用什么內存管理方式，也就等價于對這個互斥鎖使用什么內存管理方式。

         借助于 RAII ，以后我們可以只討論內存資源的管理方式，其它資源的管理方式可以使用 RAII 來同樣的實現。現在我們已經很自然的獲得了資源管理的 3 種方式：基于堆的動態方式、基于棧的自動方式和全局。值得一提的是，這 3 種方式中比較不容易出錯的后兩種實際上可以解決大部分的資源管理需求。因為絕大部分資源，都屬于獲取 - 使用 - 釋放型的，例如很多同步對象，文件鎖， WinGDI 里的許多 GDI 對象。我們缺乏管理的，只有那些一次獲得，多個環境擁有，并且只能有一次釋放的少數資源。

         回到內存模型來看，有一點讓我們無法將內存與其它資源等同（反過來，把其它資源和內存等同卻是可以的），那就是循環引用。 A 內存可以持有指向 B 內存的引用， B 內存也可以反過來持有 A 內存的引用。循環引用導致內存管理不可以用“是否有指向該內存的引用”來區分一塊內存是否可以回收。從而喪失了一個絕佳的管理手段。但是在沒有循環引用的場合下，我們還是有非常簡潔高效的管理方法的。那就是引用計數。

         引用計數是在沒有循環引用場合下進行內存管理的絕佳手段，它具有輕量、高效、即時、可控的優點。而且在 C++ 里，引用計數已經非常成熟，只需要使用 boost.shared_ptr 或者其它非官方的引用計數指針庫就可以了，而且據悉 C++09 很可能把 boost.shared_ptr 納入標準庫。引用計數的原則是，如果一個對象沒有別的指針或引用來指向它，那么這個對象就是可以釋放的。具體的手法有大把大把的資料可以查閱，這里就不詳細說明了。引用計數通常可以處理哪些場合的資源管理問題呢？首先，對于單方向的資源管理，也就是多個 A 的實體擁有 1 個 B ，然而 B 并不會反過來依賴于 A （例如多個對象共享一個日志），引用計數是非常合適的。其次，對于擁有 - 反作用的場合，也就是 1 個或多個 A 的實體擁有 1 個或多個 B ，而 B 也擁有這些 A 的實體的引用，但是 B 的生存期仍然決定于 A 的生存期（例如父窗口擁有若干子窗口，子窗口也具有 parent 指針指向父窗口，但是子窗口的生存期決定于父窗口的生存期），這個時候 A 可以對 B 使用引用計數指針，而 B 可以對 A 使用原生的普通指針，同樣的可以很好的解決問題。

         現在所剩下的，就只有生存期的循環依賴了。如果 AB 互相持有對方的引用，而且 AB 互相的存在都依賴于對方，這樣引用計數就無法解決了。但是如果仔細想一下就會發現，這種情況在 C++ 里幾乎不可能存在。生存期循環依賴只有 2 種后果，要么 A 和 B 的析構函數里互相析構（當然就掛了），要么互相都不析構（當然就泄露了）。而這兩種都是在正常編程中不會出現的情況。所以如果即使僅僅使用引用計數，我們也可以解決幾乎所有的資源管理問題。

現在還剩下那么一丁點極少出現的不能處理的情況，我們可以使用更加復雜的 gc 來實現。可惜的是，實現一個 gc 所要耗費的精力實在太大，而且幾乎不可避免的要成為侵入式的庫。所以有點得不償失。而且 gc 通常會產生更多的毛病：

1．               你無法卻知對象析構的具體時間，從而無法真正知道影響程序性能的瓶頸在什么地方。

2．               gc 都傾向于大量的使用內存，直到內存不夠的時候再進行清理，這樣會導致程序的內存用量嚴重顛簸，并且產生大量的換頁。

3．               過度的依賴于 gc 會使程序員大量的把可以由之前提到的各種方法來處理的資源交給 gc 來處理，無故的加重了 gc 的負擔。

4．               gc 的管理方法和 C++ 的析構函數有可能產生語義上的沖突。

這就是為什么 C++ 標準對垃圾回收的態度如此惡劣的原因。

 

我們現在回過頭來看 Java/C# 這樣的內置 gc 的語言。這樣的語言由于使用了 gc ，就不可避免的放棄了析構函數。為什么 gc 會和析構函數產生沖突呢？一個 gc 一般會希望在進行垃圾回收的時候，整個過程是一個原子的，但析構函數會破壞這一點，在釋放內存的時候如果還要執行代碼，那么難免會對整個 gc 環境產生破壞性的影響。由于沒有析構函數，這些語言就不可能做到 RAII ，也就是說，它們的 gc 所能夠管理的，也就僅僅只有內存而已了。對于其他資源， Java 等就必須手動釋放。雖然 C# 提供了 with 關鍵字來緩解這一問題，但仍然無法徹底的解決。

還有什么麻煩呢？之前說的那 4 點全部都有。雖然 JVM 的速度在不斷的提高，但是內存使用這一點卻完全沒有發展，不能不說是 gc 說導致。它所帶來了什么好處呢？是內存管理的自動化，而不是資源管理的自動化。

 

所以說 C++ 并不是世人所想象的那樣需要 gc ， C++ 本身就已經提供了足夠強大的資源管理能力。基于棧的自動管理，或者使用引用計數，幾乎可以達到和 gc 同樣的覆蓋面，而且沒有 gc 的那些問題， RAII 使得 C++ 在管理非內存資源的時候還更加有優勢，為什么不使用呢？

 

ps. 設計一個非官方的 gc 庫還是可以的。但是畢竟不會成為主流了。

發信人:?ufoer?(我有一雙黑色的眼睛),?板面:?Religion
標??題:?[轉載]?人生三重境界
發信站:?飄渺水云間?(Sat?Jan?13?13:22:14?2007),?轉信

【?原文由?abbr?發表于?ZJUOnline?討論區?】???????????????????????????????????????????????????????????????????????????????
人生有三重境界，這三重境界可以用一段充滿禪機的語言來說明，這段語言便是：
　　看山是山，看水是水；
　　看山不是山，看水不是水；
　　看山還是山。看水還是水。
　　這就是說一個人的人生之初純潔無瑕，初識世界，一切都是新鮮的，眼睛看見什
么就是什么，人家告訴他這是山，他就認識了山；告訴他這是水，他就認識了水。

　　隨著年齡漸長，經歷的世事漸多，就發現這個世界的問題了。這個世界問題越來
越多，越來越復雜，經常是黑白顛倒，是非混淆，無理走遍天下，有理寸步難行，好
人無好報，惡人活千年。進人這個階段，人是激憤的，不平的，憂慮的，疑問的，警
惕的，復雜的。人不愿意再輕易地相信什么。人到了這個時候看山也感慨，看水也嘆
息，借古諷今，指桑罵槐。山自然不再是單純的山，水自然不再是單純的水。一切的
一切都是人的主觀意志的載體，所謂“好風憑借力，送我上青云”。一個人倘若停留
在人生的這一?階段，那就苦了這條性命了。人就會這山望了那山高，不停地攀登，
爭強好勝，與人比較，怎么做人，如何處世，絞盡腦汁，機關算盡，永無休止和滿足
的一天。因為這個世界原本就是一個圓的，人外還有人，天外還有天，循環往復，綠
水長流。而人的生命是短暫的有限的，哪里能夠去與永恒和無限計較呢？
　　許多人到了人生的第二重境界就到了人生的終點。追求一生．勞碌一生，心高氣
傲一生，最后發現自己并沒有達到自己的理想，于是抱恨終生。但是有些人通過自己
的修練，終于把自己提升到了第三重人生境界。茅塞頓開，回歸自然。人這個時候便
會專心致志做自己應該做的事情，不與旁人有任何計較。任你紅塵滾滾，我自清風朗
月。面對?蕪雜世俗之事，一笑了之，了了有何不了，這個時候的人看山又是山，看
水又是水了。正是：人本是人，不必刻意去做人；世本是世，無須精心去處世；便也
就是真正的做人與處世了。
--

隕石疾馳的絢爛會消逝在無盡的夜空
但恒星的光輝依舊閃耀在蒼穹
明星顯赫的聲名將淡出于大眾的記憶
而他們的旋律永遠被靈魂傳誦

※?來源:·飄渺水云間?freecity.cn·[FROM:?beyondgenius]??????????????????????????????????????????????????????????????????
--
※?轉載:·飄渺水云間?freecity.cn·[FROM:?abbr]??????????????????????????????????????????????????????????????????????????
--
※?轉載:·飄渺水云間?freecity.cn·[FROM:?ufoer]?????????????????????????????????????????????????????????????????????????
詳解link
有些人寫C/C++(以下假定為C++)程序，對unresolved external link或者duplicated external simbol的錯誤信息不知所措（因為這樣的錯誤信息不能定位到某一行）。或者對語言的一些部分不知道為什么要（或者不要）這樣那樣設計。了解本文之后，或許會有一些答案。
    首先看看我們是如何寫一個程序的。如果你在使用某種IDE（Visual Studio，Elicpse，Dev C++等），你可能不會發現程序是如何組織起來的（很多人因此而反對初學者使用IDE）。因為使用IDE，你所做的事情，就是在一個項目里新建一系列的.cpp和.h文件，編寫好之后在菜單里點擊“編譯”，就萬事大吉了。但其實以前，程序員寫程序不是這樣的。他們首先要打開一個編輯器，像編寫文本文件一樣的寫好代碼，然后在命令行下敲
    cc 1.cpp -o 1.o
    cc 2.cpp -o 2.o
    cc 3.cpp -o 3.o
這里cc代表某個C/C++編譯器，后面緊跟著要編譯的cpp文件，并且以-o指定要輸出的文件（請原諒我沒有使用任何一個流行編譯器作為例子）。這樣當前目錄下就會出現：
    1.o 2.o 3.o
最后，程序員還要鍵入
    link 1.o 2.o 3.o -o a.out
來生成最終的可執行文件a.out。現在的IDE，其實也同樣遵照著這個步驟，只不過把一切都自動化了。
    讓我們來分析上面的過程，看看能發現什么。
    首先，對源代碼進行編譯，是對各個cpp文件單獨進行的。對于每一次編譯，如果排除在cpp文件里include別的cpp文件的情況（這是C++代碼編寫中極其錯誤的寫法），那么編譯器僅僅知道當前要編譯的那一個cpp文件，對其他的cpp文件的存在完全不知情。
    其次，每個cpp文件編譯后，產生的.o文件，要被一個鏈接器(link)所讀入，才能最終生成可執行文件。
    好了，有了這些感性認識之后，讓我們來看看C/C++程序是如何組織的。
    
    首先要知道一些概念：
    編譯：編譯器對源代碼進行編譯，是將以文本形式存在的源代碼翻譯為機器語言形式的目標文件的過程。
    編譯單元：對于C++來說，每一個cpp文件就是一個編譯單元。從之前的編譯過程的演示可以看出，各個編譯單元之間是互相不可知的。
    目標文件：由編譯所生成的文件，以機器碼的形式包含了編譯單元里所有的代碼和數據，以及一些其他的信息。
    
    下面我們具體看看編譯的過程。我們跳過語法分析等，直接來到目標文件的生成。假設我們有一個1.cpp文件
     int n = 1;

    void f()
     {
        ++n;
    }

    它編譯出來的目標文件1.o就會有一個區域（假定名稱為2進制段），包含了以上數據／函數，其中有n, f，以文件偏移量的形式給出很可能就是：
    偏移量    內容    長度
    0x000    n    4
    0x004    f     ??
    注意：這僅僅是猜測，不代表目標文件的真實布局。目標文件的各個數據不一定連續，也不一定按照這個順序，當然也不一定從0x000開始。
    現在我們看看從0x004開始f函數的內容（在0x86平臺下的猜測）：
    0x004 inc DWORD PTR [0x000]
    0x00? ret
    注意n++已經被翻譯為：inc DWORD PTR [0x000]，也就是把本單元0x000位置上的一個DWORD(4字節)加1。
    
    下面如果有另一個2.cpp，如下
    extern int n;
    void g()
    {
        ++n;
    }
    那么它的目標文件2.o的2進制段就應該是
    偏移量    內容    長度
    0x000    g     ??
    為什么這里沒有n的空間（也就是n的定義），因為n被聲明為extern，表明n的定義在別的編譯單元里。別忘了編譯的時候是不可能知道別的編譯單元的情況的，故編譯器不知道n究竟在何處，所以這個時候g的二進制代碼里沒有辦法填寫inc DWORD PTR [???]中的？？？部分。怎么辦呢？這個工作就只能交給后來的鏈接器去處理。為了讓鏈接器知道哪些地方的地址是沒有填好的，所以目標文件還要有一個“未解決符號表”，也就是unresolved symbol table. 同樣,提供n的定義的目標文件(也就是1.o)也要提供一個“導出符號表”，export symbol table, 來告訴鏈接器自己可以提供哪些地址。
    讓我們理一下思路：現在我們知道，每一個目標文件，除了擁有自己的數據和二進制代碼之外，還要至少提供2個表：未解決符號表和導出符號表，分別告訴鏈接器自己需要什么和能夠提供什么。下面的問題是，如何在2個表之間建立對應關系。這里就有一個新的概念：符號。在C/C++中，每一個變量和函數都有自己的符號。例如變量n的符號就是“n”。函數的符號要更加復雜，它需要結合函數名及其參數和調用慣例等，得到一個唯一的字符串。f的符號可能就是"_f"（根據不同編譯器可以有變化）。
    所以，1.o的導出符號表就是
    符號    地址
    n    0x000
    _f    0x004
    而未解決符號表為空
    2.o的導出符號表為
    符號    地址
    _g    0x000
    未解決符號表為
    符號    地址    
    n    0x001    
    這里0x001為從0x000開始的inc DWORD PTR [???]的二進制編碼中存儲???的起始地址(這里假設inc的機器碼的第2－5字節為要+1的絕對地址，需要知道確切情況可查手冊)。這個表告訴鏈接器，在本編譯單元0x001的位置上有一個地址，該地址值不明，但是具有符號n。
    鏈接的時候，鏈接器在2.o里發現了未解決符號n，那么在查找所有編譯單元的時候，在1.o中發現了導出符號n，那么鏈接器就會將n的地址0x000填寫到2.o的0x001的位置上。
    “打住”，可能你就會跳出來指責我了。如果這樣做得話，豈不是g的內容就會變成inc DWORD PTR [0x000]，按照之前的理解，這是將本單元的0x000地址的4字節加1，而不是將1.o的對應位置加1。是的，因為每個編譯單元的地址都是從0開始的，所以最終拼接起來的時候地址會重復。所以鏈接器會在拼接的時候對各個單元的地址進行調整。這個例子中，假設2.o的0x00000000地址被定位在可執行文件的0x00001000上，而1.o的0x00000000地址被定位在可執行文件的0x00002000上，那么實際上對鏈接器來說，1.o的導出符號表其實
    符號    地址
    n    0x000 + 0x2000
    _f    0x004 + 0x2000
    而未解決符號表為空
    2.o的導出符號表為
    符號    地址
    _g    0x000 + 0x1000
    未解決符號表為
    符號    地址            
    n    0x001 + 0x1000
所以最終g的代碼會變為inc DWORD PTR [0x000 + 0x2000]。
    最后還有一個漏洞，既然最后n的地址變為0x2000了，那么以前f的代碼inc DWORD PTR [0x000]就是錯誤的了。所以目標文件為此還要提供一個表，叫做地址重定向表address redirect table。
    對于1.o來說，它的重定向表為
    地址
    0x005
    這個表不需要符號，當鏈接器處理這個表的時候，發現地址為0x005的位置上有一個地址需要重定向，那么直接在以0x005開始的4個字節上加上0x2000就可以了。
    讓我們總結一下：編譯器把一個cpp編譯為目標文件的時候，除了要在目標文件里寫入cpp里包含的數據和代碼，還要至少提供3個表：未解決符號表，導出符號表和地址重定向表。
    未解決符號表提供了所有在該編譯單元里引用但是定義并不在本編譯單元里的符號及其出現的地址。
    導出符號表提供了本編譯單元具有定義，并且愿意提供給其他編譯單元使用的符號及其地址。
    地址重定向表提供了本編譯單元所有對自身地址的引用的記錄。
    鏈接器進行鏈接的時候，首先決定各個目標文件在最終可執行文件里的位置。然后訪問所有目標文件的地址重定向表，對其中記錄的地址進行重定向（即加上該編譯單元實際在可執行文件里的起始地址）。然后遍歷所有目標文件的未解決符號表，并且在所有的導出符號表里查找匹配的符號，并在未解決符號表中所記錄的位置上填寫實際的地址（也要加上擁有該符號定義的編譯單元實際在可執行文件里的起始地址）。最后把所有的目標文件的內容寫在各自的位置上，再作一些別的工作，一個可執行文件就出爐了。
    最終link 1.o 2.o .... 所生成的可執行文件大概是
    0x00000000  ????（別的一些信息）
    ....
    0x00001000  inc DWORD PTR [0x00002000]              //這里是2.o的開始，也就是g的定義
    0x00001005  ret                                  //假設inc為5個字節，這里是g的結尾
    ....
    0x00002000  0x00000001                           //這里是1.o的開始，也是n的定義（初始化為1）
    0x00002004  inc DWORD PTR [0x00002000]         //這里是f的開始
    0x00002009  ret                                  //假設inc為5個字節，這里是f的結尾
    ...
    ...
    實際鏈接的時候更為復雜，因為實際的目標文件里把數據／代碼分為好幾個區，重定向等要按區進行，但原理是一樣的。


    
    現在我們可以來看看幾個經典的鏈接錯誤了：
    unresolved external link..
    這個很顯然，是鏈接器發現一個未解決符號，但是在導出符號表里沒有找到對應的項。
    解決方案么，當然就是在某個編譯單元里提供這個符號的定義就行了。（注意，這個符號可以是一個變量，也可以是一個函數），也可以看看是不是有什么該鏈接的文件沒有鏈接
    duplicated external simbols...
    這個則是導出符號表里出現了重復項，因此鏈接器無法確定應該使用哪一個。這可能是使用了重復的名稱，也可能有別的原因。


    我們再來看看C/C++語言里針對這一些而提供的特性：
    extern:這是告訴編譯器，這個符號在別的編譯單元里定義，也就是要把這個符號放到未解決符號表里去。（外部鏈接）
    
    static:如果該關鍵字位于全局函數或者變量的聲明的前面，表明該編譯單元不導出這個函數／變量的符號。因此無法在別的編譯單元里使用。（內部鏈接）。如果是static局部變量，則該變量的存儲方式和全局變量一樣，但是仍然不導出符號。
    
    默認鏈接屬性：對于函數和變量，模認外部鏈接，對于const變量，默認內部鏈接。（可以通過添加extern和static改變鏈接屬性）

    外部鏈接的利弊：外部鏈接的符號，可以在整個程序范圍內使用（因為導出了符號）。但是同時要求其他的編譯單元不能導出相同的符號（不然就是duplicated external simbols)

    內部鏈接的利弊：內部鏈接的符號，不能在別的編譯單元內使用。但是不同的編譯單元可以擁有同樣名稱的內部鏈接符號。

    為什么頭文件里一般只可以有聲明不能有定義：頭文件可以被多個編譯單元包含，如果頭文件里有定義，那么每個包含這個頭文件的編譯單元就都會對同一個符號進行定義，如果該符號為外部鏈接，則會導致duplicated external simbols。因此如果頭文件里要定義，必須保證定義的符號只能具有內部鏈接。

    為什么常量默認為內部鏈接，而變量不是：
        這就是為了能夠在頭文件里如const int n = 0這樣的定義常量。由于常量是只讀的，因此即使每個編譯單元都擁有一份定義也沒有關系。如果一個定義于頭文件里的變量擁有內部鏈接，那么如果出現多個編譯單元都定義該變量，則其中一個編譯單元對該變量進行修改，不會影響其他單元的同一變量，會產生意想不到的后果。

    為什么函數默認是外部鏈接：
        雖然函數是只讀的，但是和變量不同，函數在代碼編寫的時候非常容易變化，如果函數默認具有內部鏈接，則人們會傾向于把函數定義在頭文件里，那么一旦函數被修改，所有包含了該頭文件的編譯單元都要被重新編譯。另外，函數里定義的靜態局部變量也將被定義在頭文件里。

    為什么類的靜態變量不可以就地初始化：所謂就地初始化就是類似于這樣的情況：
        class A
        {
            static char msg[] = "aha";
        };
不允許這樣做得原因是，由于class的聲明通常是在頭文件里，如果允許這樣做，其實就相當于在頭文件里定義了一個非const變量。

    在C++里，頭文件定義一個const對象會怎么樣：
        一般不會怎么樣，這個和C里的在頭文件里定義const int一樣，每一個包含了這個頭文件的編譯單元都會定義這個對象。但由于該對象是const的，所以沒什么影響。但是：有2種情況可能破壞這個局面：
        1。如果涉及到對這個const對象取地址并且依賴于這個地址的唯一性，那么在不同的編譯單元里，取到的地址可以不同。（但一般很少這么做）
        2。如果這個對象具有mutable的變量，某個編譯單元對其進行修改，則同樣不會影響到別的編譯單元。

    為什么類的靜態常量也不可以就地初始化：
        因為這相當于在頭文件里定義了const對象。作為例外，int/char等可以進行就地初始化，是因為這些變量可以直接被優化為立即數，就和宏一樣。

    內聯函數：
        C++里的內聯函數由于類似于一個宏，因此不存在鏈接屬性問題。

    為什么公共使用的內聯函數要定義于頭文件里：
        因為編譯時編譯單元之間互相不知道，如果內聯函數被定義于.cpp文件中，編譯其他使用該函數的編譯單元的時候沒有辦法找到函數的定義，因此無法對函數進行展開。所以說如果內聯函數定義于.cpp文件里，那么就只有這個cpp文件可以是用這個函數。

    頭文件里內聯函數被拒絕會怎樣：
        如果定義于頭文件里的內聯函數被拒絕，那么編譯器會自動在每個包含了該頭文件的編譯單元里定義這個函數并且不導出符號。

    如果被拒絕的內聯函數里定義了靜態局部變量，這個變量會被定義于何處：
        早期的編譯器會在每個編譯單元里定義一個，并因此產生錯誤的結果，較新的編譯器會解決這個問題，手段未知。

    為什么export關鍵字沒人實現：
        export要求編譯器跨編譯單元查找函數定義，使得編譯器實現非常困難。




  編譯和靜態鏈接就分析到這里，我會帶著動態鏈接和load的詳解殺回來