@ff
你可以寫個簡單的程序測試一下，是可以的

繼承型的行為模式

和STL算法模板 + functor思想相似
不過一個編譯時靜態(tài)、一個運行時動態(tài)

VC6的STL在C++標準化之前，支持得很差
VS.NET后好多了

靜態(tài)的多態(tài)還是有用的時候，C++ Modern Design詳解
當然項目中的話，維護人員要求高了點。。。

static該區(qū)分一下C和C++的，因為C++還有類就多了與普通成員的區(qū)別，

static函數(shù)就知道限制可見范圍只在本文件中，C++中推薦用匿名namespace替代,

至于那個普通函數(shù)在內(nèi)存中有拷貝就不知所云了

文學(xué)表達很好，
侯捷的書籍受歡迎的原因除了深入淺處的分析外，就是文筆
樓主的技術(shù)鉆研精神也值得偶們學(xué)習(xí)

他們都回答了嘛，而且太詳細了的說，歷史都被搬出來了
兩種都可以被編譯器接受，只是用實例訪問的方式已經(jīng)不推薦使用了
至于MSDN上那個，也許是寫文檔的開發(fā)人員堅持第二種吧

呵呵，都是Effective STL里面的條目啊
那個12點有點詭異，也容易忘記，不過知道remove的原理就容易記住了

STL里面的heap的幾個函數(shù)很精辟拉~

那個參數(shù)太長，意思可以考慮把之間有相互關(guān)系的參數(shù)合并到一個類中作為成員變量，然后傳入類的實例

針對接口編程確實才是真正的OOP
用StreamReader/Writer，使得操作配置文件的都針對這個接口來操作，而不關(guān)心數(shù)據(jù)從哪兒來，當然個人覺得，GetValue/SetValue的接口應(yīng)該和Open/Save分開，打開數(shù)據(jù)和保存數(shù)據(jù)的操作一般是開始和結(jié)束的，而使用GetValue/SetValue則可能到處都使用，不過還是看你應(yīng)用了，抽象和分離職責是OOP設(shè)計中的最難的。

設(shè)計個好的比較通用的配置庫確實不容易，以前參考過apache的jakarta commons的Configuration的項目，但是終覺得對C++不適合，缺少的東西太多，人家Java畢竟不只是語言，而更是一個平臺。 也看過eMule等開源軟件的配置設(shè)計，感覺五花八門，什么都有，得出的結(jié)論是針對具體的項目寫，通用的太難。

以上大俠提到的boost的serialization還沒看過，是在io的庫中嗎？不過boost的都是好東東的說，:)

1，關(guān)鍵是抽象吧，設(shè)計的難點
2，偶也感覺很頭疼的，找不到一個合適的log庫，log4cxx等都有好多無法容忍的缺點，自己改寫小點吧，又好累~~
3和4，呵呵，Effective C++里面討論得不少
5，使用文件這種方法很局限，缺點太多，最重要的等于是給這個類強加了一個讀取文件的依賴。如果參數(shù)太長，應(yīng)該考慮重構(gòu)，用類來替代，至于類實例的初始化，從文件讀取還是從網(wǎng)絡(luò)讀取，那是新的類的職責了

6，所有變量private，部分變量可以在提供protected或者public的accessor方法

7，很多函數(shù)都會需要創(chuàng)建新堆對象，用std::auto_ptr或者boost::shared_ptr吧

2005的Debug運行最近總是提示找不到MSVCR80D.dll，但是Release版本卻能找到，樓上的兄弟可知道怎么回事
后來把本來在Assembly下面的相關(guān)的文件拷貝到System32目錄下面，報錯好像是side by side 什么的，無法執(zhí)行，是不是和manifest有關(guān)
如何解決？
謝了先