eXile 的專欄

模板用得多的，好象就是SmartWin 和 WTL...
我覺得成熟的C++ GUI庫，除了ＭＦＣ，也就是Qt 和 wxWidgets
Qt的元對象機制就是不合標準，其實用起來是很方便的

CxxTest需要預處理, windows上還得安裝Python, 作者要是直接提供一個可執行文件就好了

"需要注釋的地方, 也就是需要重構的地方.”
這句話的意思是: 良好的代碼是自我注釋的.

閣下的模板技術比我還牛....

呵呵, 當你好不不容易把文檔寫出來, 卻又發現程序又要改來改去. 以前寫的文檔又不適用了. 比沒有文檔更可怕的是錯誤的文檔.
所以我覺得開發文檔相對次要, 首先要注重的是, 良好的風格, 獨立的模塊, 清晰的結構 .
<<重構>>中有一句話: 需要注釋的地方, 也就是需要重構的地方.

我的感覺是：天亮了，解放了，不用再回到萬惡的舊社會了。。。

雙重鎖同樣是不安全的，所以盡量不要采用lazy initialization，
對于early initialization, 一種安全的辦法可以參見：
http://www.shnenglu.com/eXile/archive/2006/09/27/13034.html

對于ＭＳ ＶＳ， c++標準的支持實在是不能抱什么希望，要用C++0x，看來還得是gcc, gcc４.3估計今年就能推出，它支持C++0x的絕大部分特征

極限編程的出現正是在現有開發模式下出現一系列問題后的一些探索。不過，適合自己的才是最好的，如果你覺得現有的的知識和經驗可以為你解決這些問題，就沒有必要為敏捷而敏捷

開發周期可以通過軟件的的版本升級進行控制，要不軟件也不會有1.0, 2.0.....

呵呵，共同學習，共同提高。
比如說第一點：追求模塊化和開放性

模塊的高內聚，低耦合是保證這一點的基礎，怎么樣做到這一點呢？由此產生各種面向對象的設計理論，而設計模式正是在設計方法在實踐中產生的高度總結。但是做到這一點是不容易的，需要經過一定的鍛煉和積累，應用哪一種設計模式
也不是一開始就能清晰的看出來的。而使用ＴＤＤ，則強迫你做到這一點。一個模塊性不好的單元，是很難進行測試的。程序員最容易犯的毛病，是把焦點過多的集中在實現的細節上，使用ＴＤＤ，你首先必須把焦點放在功能的接囗上，而良好的接口，正是良好的設計的基礎。

不過從你所說的來看, 主要問題是, 沒有了解XP的核心概念, 卻盲目套用XP的外在形式,

呵呵, 相信只要隨便翻一翻XP的書, 都會說到這些問題. 不過我還是說一說,

1)極限編程卻放棄這種追求 ....
XP追求的正是模塊化和開放性

2)結果就是產生一大堆丑陋的代碼...
對于個人來說, 如果使用XP后寫出的代碼很丑陋, 那么可以肯定, 不使用XP寫出的代碼也不會好到那兒去; 對于開發小組來說,三個月XP實踐還存在這種看法, 項目管理只能說是太失敗了

3)為什么不在設計初期進行預防呢？
要是在設計初期就能想到所有的變化和細節, 也就不會有XP了

4)關于代碼與文檔, 測試還是調試, 網上這種文章已經太多了

5)沒有必要構造框架之類可復用的東西,無疑是與面向對象思想背道而馳的...
這只能說明你太不了解XP了,

正好在書中看到這么句話：
團隊人數加倍并不等于開發周期的減半。它可能只會縮短1/3。如果團隊超過10 個人的話，增加更多的人員可能反而會延緩項目的進度。
而且項目開發周期越長，團隊內的成員對整個項目代碼的熟悉度就越少，加上不確定的人員流動，新來人員的業務不熟等其他可能性，這項目會越來越復雜。
總的意思就是，項目人數不能太多，周期不能太長。

其實，這也是Ｃ＋＋當前所處的境遇，ＣＳＤＮ的ＢＬＯＧ首頁推薦上，甚至把Ｃ＋＋拿掉了，也難怪，它已完全變成Ｃ＋＋初學者的論壇。
對此，個人認為有幾個原因：
１）c++越來越專注于特定領域
２）高水平的C++程序員越來越少（很多人是Ｃ大牛，但不是Ｃ＋＋大牛）
３）c++自身發展的一些失誤

呵呵, 自從我知道了XP以后, 立刻就喜歡上了它, 肯定也有人不喜歡它.這是正常的. 選擇你喜歡的開發方式就對了. 不過你對XP的認識存在幾個明顯的誤區, 這些在ＸP的書里已經說得很清楚了。說實話，你所說的有幾個理由，使我甚至懷疑你是大學里面講軟件工程的教授，夸夸其談，但是和實際脫節。

也不單單是教育的問題. 也不單單是性的問題. 我覺得中國十幾歲的孩子的成長環境 , 是沒法和美國去比的.

呵呵，　不錯！我覺得作為程序員，專業的，優雅的coding會帶給人樂趣，也是自己的動力。希望多寫出一些技術心得，共同學習，共同進步！

據說對于使用ＸＰ編程的人來說，使用調試器是可恥的行為。。。

這個要看公司的定位了，大部分大老板們是不懂技術的，所以要幫他們分析一下所在的技術背景和前景，也可以給他們一些書面建議

支持。。。

算法分析和面向過程的分析好象還不太一樣吧？

翻得不錯！

因為Sigal/Slot可以跨線程，還可以指定執行的線程環境,，所以一般情況下沒有必要使用自定義事件。

我玩ＣＳ從來不頭暈，但一些菜鳥同學卻經常叫喊頭暈，原來是這個原因，我比他們精神更集中。

tc也太老了,好多庫函數都是過時的東西,要學就學標準c, 《tc函數大全》? 這本書還是扔了吧, win16時代的產物了. 建議初學者使用gcc.
使用VC, 也不要一開始就撲在MFC上. 你沒見過使用VC的IDE ,但內部是gcc編譯器吧?
一句話: 先使用標準庫.

而且前一向老外有一篇文章，說了一下什么情況下，雙重鎖會失敗，我沒有細看，總之也是不安全的

這種方式遠談不上完美，一般Ｃ＋＋的singleton實現的最大缺陷就是釋放的順序依賴問題，而象ModerC++Design那樣，又太復雜了，不實用。
所以，我現在都是用main()中的局部變量來模擬全局變量，能很好用于單件模式　。

to Galaxy :
用ＭＦＣ開發共享軟件，這不難為自己嗎.

作為一個測試程序, WriteXML 中對象的管理很混亂, 也許是lz不拘小節, 但會給人誤導...

editbin /SUBSYSTEM:CONSOLE $(TargetPath)

利用editbin不用修改代碼, 就可添加控制臺

上面的Ｘ不要有實現，這樣才能保證MemFunPtr尺寸最大

這個方法也不是不能使用，不過不要用void*, 要選擇一個更大的類型。
如下：
class X;
typedef void (X::*MemFunPtr)(void);

使用MemFunPtr，這樣就不會有截斷了。

所以, 這些東西還是使用一些成熟的實現吧!

發現一個很嚴重的錯誤: t2t 函數是錯誤的.
原因: 一個成員函數指針的大小可能4, 8, 12, 16 byte, 而32位平臺sizeof(void*)= 4, t2t會造成截斷.

to 飯中淹 :
這個實際上是如何實現代理 (delegate) 的問題, codeproject 上有很多關于它的討論.

to 夢在天涯 :
這個主要用于模塊之間的解藕

呵呵，DLL中使用shared_ptr的說明：http://www.shnenglu.com/eXile/archive/2007/04/23/22637.html

總感覺用ＭＦＣ做界面挺痛苦的。。。

老兄，我用的不是auto_ptr，而是shared_ptr,　我的做法并沒有錯。另外，在復雜的系統中，手工管理內存總是有點危險，而shared_ptr已被列為tr1標準，我們不要停留在原始社會，還是用點新技術吧！

使用IOCP, 現在有一個asio, 用起來很簡單的.
另外可不可以問一個問題: UDP采用IOCP有沒有優化效果?

如果是針對C++客戶, 那么采用boost::shared_ptr可以大大減輕內存的管理, 不容易產生內存泄露, 也不會有跨模塊釋放內存的情況.

與 asio 相比, ACE 用起來實在是太麻煩了. asio 的易用性沒得說.

我前一向剛好做過類似的東西, 用C++實現, 只要不要求動態生成, 其實還是很簡單的, 只要實現了基本的數值類型, 字符串就可以, 其它對象都是它們的組合, 另外還要考慮以下方面:(1)支持標準容器 (2)字節序的問題

可以參考 MFC 中CArchive 與 boost 序列化庫的實現. 另外, boost 提供了xml, text, binary 多種形式, 你也可以直接使用它們, 不一定非要自己做一個

tangram中界面如何同C++對象交互啊, 通過COM接口嗎?

前幾日看到有位大哥發布的 ADO 數據庫的封裝，到處是模板，不免有些頭暈....

呵呵，是說的我嗎？關于模板，我的看法是，在做庫的封裝時，可以無所顧忌地使用，以作最大優化，在做業務邏輯時，盡量不要使用，以便于維護。

我做的封裝，如下所示，表中有哪些字段，什么類型，一目了然，在此引入模板我覺得是必要的。
struct TUser
{
AdoCol<int> m_id;
AdoCol<std::string> m_name;
AdoCol<int> m_type;
AdoCol<AdoBLOB> m_blob;
};

這兩行是錯誤的：
　cout << TEXT("輸入新的 C 盤卷標： ");
cin >> volumeName;
cin, cout并不能處理UNICODE，按照Microsoft的風格，可能也要定義一個tin, tout...

要支持UNICODE，各式各樣的字符串處理才是困難的地方。

1)打印出被刪除的元素, 很簡單
struct MyPred
{
bool operator()(int n) const
{
if(n%2 == 0) {cout << "Erasing " << n << endl; return true; }
else return false;
}
};

vector<int> v;
vector_erase_if(v, MyPred());
2)list提供了remove方法，但是set,map沒有
（實際上這幾行代碼都是從STL的list源碼中抄出來的，主要用于set 和map);

// for vector, deque

template <class Container, class T>
inline
void vector_erase(Container & c, T const& t)
{
c.erase(std::remove(c.begin(), c.end(), t), c.end());
}

template <class Container, class Pred>
inline
void vector_erase_if(Container & c, Pred pred)
{
c.erase(std::remove_if(c.begin(), c.end(), pred), c.end());
}

// for list, set, map
template <class Container, class T>
void list_erase(Container & c, T const& t)
{
typename Container::iterator
b = c.begin(), e = c.end(), prev = b;
while (b != e)
{
++b;
if (*prev == t) c.erase(prev);
prev = b;
}
}

template <class Container, class Pred>
void list_erase_if(Container & c, Pred pred)
{
typename Container::iterator
b = c.begin(), e = c.end(), prev = b;
while (b != e)
{
++b;
if (pred(*prev)) c.erase(prev);
prev = b;
}
}

不錯, 支持.