我不知道這里有多少朋友是積累了自己的一套庫的。

嗯……說明白點，比如想讀寫文件了，操作系統 API 的那堆參數我記不住，也用不著那么靈活，于是自己寫一個自己記得住的，下次碰到同樣情況繼續用，并不斷完善。哪天想讀寫注冊表了，想讀寫 INI 文件了，想讀寫 XML 文件了，想用個動態數組了，想要個鏈表、樹了，可能都會形成自己的一套東西。這套東西可能是基于已有的第三方庫，也可能是純粹自己一點一滴寫起來的。好了，我想現在我大概表達得夠明白了，這就是我說的“庫”，這個庫可能不是非常完備，但起碼是自己積累的，有著（起碼對自己來說）友好接口的東東。

可能有朋友會說，你要自己的動態數組、鏈表干嗎？STL 很好啊！你要讀寫文件的干嗎？CFile 哪里不好？你要讀 INI？不是有 API 嗎？……諸如此類。如果有朋友持這樣的觀點，我想我們是不同的一類人。如果您只是能完成某項任務就好，那么確實，不需要這些玩意兒。但是，如果哪一天這種普通的工作做得麻木了，來思考一下另一個層面的事情，您也許會覺得這些也是比較有意思的事。廢話到此。

那么，不知道這些庫，是以什么形式存在的呢？稍微極端開來講，可能有兩個做法——

第一種做法。我每寫成一個功能模塊，都是一個（或幾個）.h、一個（或幾個）.cpp，它們是自我獨立的，不依賴于任何別的東西（或者不依賴標準庫以外的東西、不依賴于操作系統 API 以外的東西）——總之是不依賴于當前編譯系統以外的東西。以后需要使用，就把那幾個文件拷到當前項目來使用。然后一個個這樣的互不依賴的功能模塊構成了我現在所擁有的庫。

第二種做法呢，就是我把這個庫作系統的規劃，劃分為很多小的功能模塊，這些功能模塊可能會彼此依賴，當庫龐大以后，甚至連你自己都該不太清楚誰依賴誰了。要使用這個庫的功能，就必須把整個庫拿進來。到最后，我將這整套東西編譯為一個 .lib，這個 .lib 的源程序會一直維護下去。但使用的時候，我就拿編譯好的 .lib 來用。

前一種做法就是標題里所說的小庫，后一種做法我稱之為大庫。我的問題是，作為個人的積累，小庫好還是大庫好？如果可能，我是比較喜歡小庫的。但是，經常會有這樣的問題，各個功能模塊中可能會涉及同一個基礎功能，而這個基礎功能我已經做過了的，到底是用還是不用？如果用，“互不依賴”就會被打破，最終會發展成一個凌亂的大庫；如果不用，我必須把代碼抄一遍，那么這兩份完全一樣的代碼在以后同步更新就比較麻煩了。再說大庫，一個規劃的很好的大庫也是不錯。但是前期積累的時候，往往沒法規劃；就算等到有一定的積累了以后再來積累，也會在模塊組織上猶豫不決：我到底要不要來一個統一的 typedef 作為我的類型系統？當我實現了 MyVector，MyString 以后，我的后續代碼勢必都會使用它們，那么與別人之間的代碼交流就成了問題了。

我最近一直困惑于這個問題。而我本人對此的理解也就如上文所述。希望有朋友指教、賜教。謝謝~~！