在我自己寫的一個工廠類實現中，每個產品會注冊創建接口到這個工廠類。工廠類使用這些
注冊進來的創建接口來完成產品的創建。其結構大致如下：
product *factory::create( long product_type )
{
creator c = m_creators[product_type];
return c();
}
factory::instance().register( PRODUCT_A_TYPE, productA::create );
...
factory::instance().create( PRODUCT_A_TYPE );
這個很普通的工廠實現中，需要寫上很多注冊代碼。每次添加新的產品種類時，也需要修改
這些的注冊代碼。而恰好，這些注冊代碼可能會被放在一個統一的地方。為了消除這個地方
，我使用了偶然間看到的<Modern C++ design>里的做法：
const bool _local = factory::instance().register( PRODUCT_A_TYPE,...
也就是說，通過對全局常量_local的自動初始化，來自動完成對該產品的注冊。
結果，因為這些代碼全部被放置于一個靜態庫。最終的代碼文件結構大致為：
lib
- product_a.cpp : 定義了全局常量_local
- product_a.h
- factory.cpp
- factory.h
exe
- main.cpp
現在看起來世界很美，因為factory甚至不知道世界上還有個跟上層邏輯相關的product_a。
這種模塊耦合幾乎為0的結構讓我竊喜。
悲劇的事情首先發生于，開VC調試器，發現打在product_a.cpp里的斷點失效。就是那個總
是提示說沒有為該文件加載調試符號。開始還不在意，以為又是代碼和調試符號文件不匹配
的原因，折騰了好久，不得其果。
后來分析了下，發現這個調試提示，就像我開著調試器打開了一個非本工程的代碼文件，而
斷點就打在這個文件里一樣。也就是說，VC把我product_a.cpp當成不是這個工程里的代碼
文件。
按照這個思路寫些實驗代碼，最終發現問題所在：VC鏈接器根本沒鏈接進product_a.cpp里
的代碼。表現出來的情況就是，該編譯單元里的全局常量（全局變量一樣）根本沒有得到初
始化，因為我跟到factory::register并沒有被調用到。為什么VC不鏈接這個編譯單元對應
的目標文件？或者說，為什么VC不初始化這個全局常量？
原因就在于，product_a.cpp太獨立了。一個在整個編譯鏈接階段都無法確定該文件是否被
使用的文件，VC就直接不鏈接了。相反，當在factory.cpp里寫下類似代碼：
void test()
{
product_a obj;
}
雖然說test函數不會被調用，一切情況也變得正常了。好了，不扯了，給最后我的結論：
1、如果靜態庫中某個編譯單元在編譯階段被確認為它并沒有被外部使用，那么當這個靜態
庫被鏈接進可執行文件時，鏈接器忽略掉該編譯單元里的代碼，那么，鏈接器自然也不會為
該編譯單元里出現的全局變量常量生成初始化代碼（關于這部分初始化代碼可以閱讀
<linker and loader>一書）；
2、上面那條結論存在一種傳染性，意思是，當可執行文件里的代碼使用到靜態庫中文件A里
的代碼，A里又有地方使用到B里的代碼，那么B依然會被鏈接。這種依賴性，應該可以讓編
譯器在編譯階段就發現（顯然，上面我舉的例子里，factory只有在運行期間才會依賴到
product_a.cpp里的代碼）