eXile 的專欄

模板用得多的，好象就是SmartWin 和 WTL...
我覺得成熟的C++ GUI庫，除了ＭＦＣ，也就是Qt 和 wxWidgets
Qt的元對象機(jī)制就是不合標(biāo)準(zhǔn)，其實(shí)用起來是很方便的

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

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

閣下的模板技術(shù)比我還牛....

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

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

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

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

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

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

呵呵，共同學(xué)習(xí)，共同提高。
比如說第一點(diǎn)：追求模塊化和開放性

模塊的高內(nèi)聚，低耦合是保證這一點(diǎn)的基礎(chǔ)，怎么樣做到這一點(diǎn)呢？由此產(chǎn)生各種面向?qū)ο蟮脑O(shè)計(jì)理論，而設(shè)計(jì)模式正是在設(shè)計(jì)方法在實(shí)踐中產(chǎn)生的高度總結(jié)。但是做到這一點(diǎn)是不容易的，需要經(jīng)過一定的鍛煉和積累，應(yīng)用哪一種設(shè)計(jì)模式
也不是一開始就能清晰的看出來的。而使用ＴＤＤ，則強(qiáng)迫你做到這一點(diǎn)。一個模塊性不好的單元，是很難進(jìn)行測試的。程序員最容易犯的毛病，是把焦點(diǎn)過多的集中在實(shí)現(xiàn)的細(xì)節(jié)上，使用ＴＤＤ，你首先必須把焦點(diǎn)放在功能的接囗上，而良好的接口，正是良好的設(shè)計(jì)的基礎(chǔ)。

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

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

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

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

3)為什么不在設(shè)計(jì)初期進(jìn)行預(yù)防呢？
要是在設(shè)計(jì)初期就能想到所有的變化和細(xì)節(jié), 也就不會有XP了

4)關(guān)于代碼與文檔, 測試還是調(diào)試, 網(wǎng)上這種文章已經(jīng)太多了

5)沒有必要構(gòu)造框架之類可復(fù)用的東西,無疑是與面向?qū)ο笏枷氡车蓝Y的...
這只能說明你太不了解XP了,

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

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

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

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

呵呵，　不錯！我覺得作為程序員，專業(yè)的，優(yōu)雅的coding會帶給人樂趣，也是自己的動力。希望多寫出一些技術(shù)心得，共同學(xué)習(xí)，共同進(jìn)步！

據(jù)說對于使用ＸＰ編程的人來說，使用調(diào)試器是可恥的行為。。。

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

支持。。。

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

翻得不錯！

因?yàn)镾igal/Slot可以跨線程，還可以指定執(zhí)行的線程環(huán)境,，所以一般情況下沒有必要使用自定義事件。

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

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

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

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

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

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

editbin /SUBSYSTEM:CONSOLE $(TargetPath)

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

上面的Ｘ不要有實(shí)現(xiàn)，這樣才能保證MemFunPtr尺寸最大

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

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

所以, 這些東西還是使用一些成熟的實(shí)現(xiàn)吧!

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

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

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

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

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

老兄，我用的不是auto_ptr，而是shared_ptr,　我的做法并沒有錯。另外，在復(fù)雜的系統(tǒng)中，手工管理內(nèi)存總是有點(diǎn)危險，而shared_ptr已被列為tr1標(biāo)準(zhǔn)，我們不要停留在原始社會，還是用點(diǎn)新技術(shù)吧！

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

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

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

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

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

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

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

呵呵，是說的我嗎？關(guān)于模板，我的看法是，在做庫的封裝時，可以無所顧忌地使用，以作最大優(yōu)化，在做業(yè)務(wù)邏輯時，盡量不要使用，以便于維護(hù)。

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

這兩行是錯誤的：
　cout << TEXT("輸入新的 C 盤卷標(biāo)： ");
cin >> volumeName;
cin, cout并不能處理UNICODE，按照Microsoft的風(fēng)格，可能也要定義一個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沒有
（實(shí)際上這幾行代碼都是從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;
}
}

不錯, 支持.