@陳梓瀚(vczh)
不錯，確實如你所說，這東西強(qiáng)迫人手動去維護(hù)依賴關(guān)系
如果不這么做，就無法從中得到任何好處

至于手動collect，在我看來和后臺自動collect無啥區(qū)別

很cool
不愧是6年的經(jīng)驗
唯此一篇爾

onMessage的時候用一個for肯定是不行的，這樣你用map的意義何在

N年前你就知道office2007的style了
真的假的啊。。。。

我不要MFC，我要的是wxWidget
不過，你好好干吧

提問：
為啥網(wǎng)絡(luò)傳輸要選擇big-endian？

看到了不得的東西
留名關(guān)注

好大一個坑

原來shareSkeletonInstanceWith可以這么用
單一裝備套上整個骨架，然后把無關(guān)骨頭權(quán)重設(shè)置為0
cool

確實很水
連回復(fù)都那么水。。。。
日志啊，除了data analysis source能正常使用之外
關(guān)鍵時刻指望它能查bug？門都沒有

對你的想法表示肯定
呵呵

看起來能用來做蜘蛛

哈哈。。。。
C++選項以前有，后來就沒有了
不過無所謂，所謂C++/C#，在著色上不差什么的

由消息構(gòu)成的錄像文件，是xml格式的
當(dāng)然，這是指加密前。
經(jīng)過嚴(yán)格的加密算法處理后，錄像文件至少不會被一般人破解

@richardhe
留言已發(fā)送

感謝你的回復(fù)～

處理$END的地方，確實存在沒有處理換行的問題。

有關(guān)$NODE<>的建議非常好，不過濫用的話會使得樣式文件的可讀性不佳，因為節(jié)點的遍歷已經(jīng)不是簡單的由父到子，而變得可以上竄下跳了。

在一段代碼內(nèi)使用父節(jié)點數(shù)據(jù)的可能性不是很大。多數(shù)情況下，都可以通過多個樣式文件實現(xiàn)重新從根節(jié)點開始訪問：
h_replace -x data.xml -t css1 > a.cpp
h_replace -x data.xml -t css2 > b.cpp
h_replace -x data.xml -t css3 > c.cpp

呵呵，具備基本功能后，打算share代碼嗎？

我當(dāng)然希望和同事共同努力，只是多數(shù)人對單元測試并沒有太多認(rèn)識，而我現(xiàn)在也沒有信心能把這里面的概念向大家講清楚，還需要再做些摸索才行

嘗試在遺留代碼中使用單元測試有一陣子了，發(fā)現(xiàn)了以下一些問題：
項目壓力
遺留代碼的代碼基非常差，解依賴消耗大量時間
所選擇的遺留代碼也是當(dāng)前的開發(fā)項目，變動比較劇烈，以前寫好通過的測試，在一段時間后，就因為依賴而失敗了，甚至編譯不能通過

今天的lump的介紹有點簡單，只是貼代碼，有種一筆帶過的感覺

@創(chuàng)建更好的解決方案
書里面講的是以無測試的系統(tǒng)為前提的，和你理解的不太一樣

這樣的情形，可以試試《修改代碼的藝術(shù)》（《Working Effectively with Legacy Code》）里面介紹的東西，應(yīng)該會有幫助。
祝你好運

不錯。這個問題確實比較容易被忽視

concept真是好東西啊
不過這個語言級的新特性，還要等兩年啊

受用

把.obj給去掉

@helixapp
應(yīng)該說效率很差，不過這個做法只是為了更方便的排查錯誤的，而并非用于避免錯誤。

呵呵。我已經(jīng)沒有精力玩復(fù)雜的游戲了，現(xiàn)在都玩不需要思考的本能操作類游戲。
最近玩極品11

@夢在天涯
不是intel的東西，是很多廠商共同維護(hù)的標(biāo)準(zhǔn)，由編譯器進(jìn)行支持

all good

del a
cpy b a

多數(shù)決定陷阱
多數(shù)表決感覺上好像很方便也很有效率，實際上，卻是再危險不過的陷阱。以多數(shù)意見為意見，絕對不能用兩種方法來解決，那就是討論跟舉手。失去匿名投票的保護(hù)，少數(shù)派的人很明顯就看出自己的弱點。所以少數(shù)派的人很容易就會產(chǎn)生情緒，疏離感，不滿，以及憤怒，最后會導(dǎo)致所有人對立，造成不信任感最后瓦解整個團(tuán)隊

@func
1.new的時候不用加鎖，一般應(yīng)該在進(jìn)入多線程前在主線程把單體new出來
2.所謂多線程編碼，僅僅是對Singleton()函數(shù)加鎖是不夠的，或者也是不必要的。將單體換成全局變量想一想，在獲取全局變量的時候根本沒加鎖這回事。
多線程要加鎖的地方在對象的算法函數(shù)中，而不是獲取對象本身。

這就是這個語言的前途
[quote]也沒有一個有效的開源社區(qū)維護(hù)，它的設(shè)計完全掌握在設(shè)計者一個人手中，它的核心代碼也沒有完全開源[/quote]

比較認(rèn)同你關(guān)于重用的理解

增加一個設(shè)置補(bǔ)充
http://www.wxwidgets.org/docs/technote/vc_ide.htm

@wx
我用VC，不過我想我不用MFC的理由說得很清楚了

又見重劍，是重劍空間的那個嗎？

我的意見和我一向的做法是，寫文檔不是給人看的，也不是給自己看的，而是不是太清楚怎么下手寫程序的時候，才寫文檔。寫文檔只不過是開始寫程序的一個準(zhǔn)備，不是用來給人看的。

[quote]
插入map是這么寫的
map<int, string>::iterator it = lmap.end();
it->first = 34;
it->second.ip = inet_ntoa(343);
[/quote]

能這么寫代碼的人····立即把他fire了，如果fire不了他，那你應(yīng)該把自己fire了。

編譯器是公司統(tǒng)一用一種的，沒法選
不過IDE就隨意了，我已經(jīng)不用VSIDE很久了，一直用editplus·····

開發(fā)周期是不能控制的，這是本質(zhì)問題，就好像5分鐘的煎蛋流程不能壓縮到5秒鐘一樣。
但是認(rèn)為通過增加人手而能縮短周期的想法是不可取的

個人比較認(rèn)同“基于策略的思路構(gòu)造的庫”，這也是我期望模板所能帶來的優(yōu)越性。

嗯，可以這么理解

最消耗上班族精力的事情，不是工作時間，而是路上時間，公交和地鐵真的很惡，每天重復(fù)的來來回回很難受啊。
另外就是，你還接私活，那就更累了

@christanxw0
嗯。確實是這樣子。
但是有得有失吧。
畢竟項目里面的消息包類型實在太龐大了，而且消息包以功能為向?qū)Фx的，如果缺少注釋其含義通常會比較含糊。

接受端區(qū)分消息類型肯定還是要ID啊。
也只有這樣才能區(qū)分消息吧。這也是沒有辦法的事情。
但是，消息包的類型不用增加，
因為SPacket::SPacket(BYTE *bBuffer, DWORD dwSize)
可以將網(wǎng)絡(luò)字節(jié)流變成SPacket對象。

不是。我覺得不要再增加更多的消息包結(jié)構(gòu)體了，不然文件我看了會真的受不了的。
比如我要調(diào)用服務(wù)器 SomeClass::SetMember，我會這樣
SPacket packet(SomeClassID,FUNC_SetMember,objID);
// push param
packet.Push(playerID);
packet.Push(status);
net.Send(socket,&packet.packet.Size());

代碼很少，所以很容易就理解了關(guān)于測試套件方面的框架。
以前一直覺得CPPUNIT太龐大而沒有去了解框架大體怎樣的。

不過在游戲編程這個領(lǐng)域，想要利用這種測試套件，想要實現(xiàn)測試自動化，感覺好難啊。

@萬連文
極是。道的領(lǐng)悟，還是要依靠經(jīng)驗來獲得啊～