浪跡天涯

感覺有點(diǎn)印象，后來翻翻EffectiveC++.chm，雜項(xiàng)->條款47:

對(duì)于不同被編譯單元中的非局部靜態(tài)對(duì)象，你一定不希望自己的程序行為依賴于它們的初始化順序，因?yàn)槟銦o法控制這種順序。讓我再重復(fù)一遍：你絕對(duì)無法控制不同被編譯單元中非局部靜態(tài)對(duì)象的初始化順序。

很自然地想知道，為什么無法控制？

這是因?yàn)椋_定非局部靜態(tài)對(duì)象初始化的 " 正確" 順序很困難，非常困難，極其困難。即使在它最普通的形式下 ---- 多個(gè)被編譯單元，多個(gè)通過隱式模板實(shí)例化所生成的非局部靜態(tài)對(duì)象（隱式模板實(shí)例化時(shí)，它們本身可能都會(huì)產(chǎn)生這樣的問題） ---- 不僅不可能確定正確的初始化順序，往往連找一個(gè)可以確定正確順序的特殊情況都不值得。

在 "混沌理論" 領(lǐng)域，有一個(gè)原理稱為 "蝴蝶效應(yīng)" 。這條原理聲稱，世界某個(gè)角落的一只蝴蝶拍動(dòng)翅膀，會(huì)對(duì)大氣產(chǎn)生微小的影響，從而導(dǎo)致某個(gè)遙遠(yuǎn)的地方天氣模式的深刻變化。稍微準(zhǔn)確一點(diǎn)來說也就是：對(duì)于某種系統(tǒng)，輸入的微小干擾會(huì)導(dǎo)致輸出徹底的變化。

軟件系統(tǒng)的開發(fā)也表現(xiàn)了自身的 "蝴蝶效應(yīng)"。一些系統(tǒng)對(duì)需求的細(xì)節(jié)高度敏感，需求發(fā)生細(xì)小的變化，實(shí)現(xiàn)系統(tǒng)的難易程度就會(huì)發(fā)生巨大的變化。例如，條款29說明，將一個(gè)隱式轉(zhuǎn)換的要求從 "String到char*" 改為 "String到const char*"，就可以將一個(gè)運(yùn)行慢、容易出錯(cuò)的函數(shù)用一個(gè)運(yùn)行快并且安全的函數(shù)來代替。

確保非局部靜態(tài)對(duì)象在使用前被初始化的問題也和上面一樣，它對(duì)你的實(shí)現(xiàn)細(xì)節(jié)十分敏感。但是，如果你不強(qiáng)求一定要訪問 "非局部靜態(tài)對(duì)象"，而愿意訪問具有和非局部靜態(tài)對(duì)象 "相似行為" 的對(duì)象（不存在初始化問題），難題就消失了。取而代之的是一個(gè)很容易解決的問題，甚至稱不上是一個(gè)問題。

這種技術(shù) ---- 有時(shí)稱為 "單一模式"（譯注：即Singleton pattern，參見 "Design Patterns" 一書）---- 本身很簡(jiǎn)單。首先，把每個(gè)非局部靜態(tài)對(duì)象轉(zhuǎn)移到函數(shù)中，聲明它為static。其次，讓函數(shù)返回這個(gè)對(duì)象的引用。這樣，用戶將通過函數(shù)調(diào)用來指明對(duì)象。換句話說，用函數(shù)內(nèi)部的static對(duì)象取代了非局部靜態(tài)對(duì)象。（參見條款M26）

這個(gè)方法基于這樣的事實(shí)：雖然關(guān)于 "非局部" 靜態(tài)對(duì)象什么時(shí)候被初始化，C++幾乎沒有做過說明；但對(duì)于函數(shù)中的靜態(tài)對(duì)象（即，"局部" 靜態(tài)對(duì)象）什么時(shí)候被初始化，C++卻明確指出：它們?cè)诤瘮?shù)調(diào)用過程中初次碰到對(duì)象的定義時(shí)被初始化。所以，如果你不對(duì)非局部靜態(tài)對(duì)象直接訪問，而用返回局部靜態(tài)對(duì)象引用的函數(shù)調(diào)用來代替，就能保證從函數(shù)得到的引用指向的是被初始化了的對(duì)象。這樣做的另一個(gè)好處是，如果這個(gè)模擬非局部靜態(tài)對(duì)象的函數(shù)從沒有被調(diào)用，也就永遠(yuǎn)不會(huì)帶來對(duì)象構(gòu)造和銷毀的開銷；而對(duì)于非局部靜態(tài)對(duì)象來說就沒有這樣的好事。

可是我們和當(dāng)年的人比卻缺少太多 信仰 理想 抱負(fù) 榮譽(yù)與使命.........

看出錯(cuò)信息好像是你把soapServerLib.cpp等文件也添加到了工程中，產(chǎn)生重復(fù)定義的錯(cuò)誤。你用gsoap生成服務(wù)器端 客戶端的文件后 并不是把生成的所有文件都拷到工程中，而只是拷貝你所需要的文件到工程目錄里，你試試。

libevent用于改造網(wǎng)絡(luò)模型需要了解哪些知識(shí)？

學(xué)習(xí)了！
不知博主是否真實(shí)測(cè)試過采用memcached的服務(wù)器性能有多少提升？

http://blog.gslin.info/2005/11/network-programming-using-libevent-i.html
好像打不開了 博主還有后續(xù)文章嗎？謝謝！

學(xué)習(xí)！

我這沒有這個(gè)問題。
環(huán)境:vs2008 vmware6.0.2-build 59824

呵呵 編譯openvpn的時(shí)候需要編譯openssl 剛編譯過！

log,我覺得關(guān)鍵的有這幾點(diǎn)：
1.記錄信息規(guī)范,便于自己調(diào)試同時(shí)也便于現(xiàn)場(chǎng)人員發(fā)現(xiàn)問題。
2.在多線程下的問題，確保log正確無誤，不能丟失。以前多線程下程序調(diào)試不對(duì)，檢查n久才懷疑到日志系統(tǒng)的問題，莫名其妙的丟了許多l(xiāng)og記錄。

記號(hào) 學(xué)習(xí)epoll時(shí)好好看看

學(xué)習(xí)了...不斷積累！

這和自己寫測(cè)試代碼有什么最大的好處？？？
剛學(xué)cppunit，不是很明白，感覺還不如自己寫測(cè)試代碼來的快！

可以的，你可以參考我的另一篇文章:
<<webservice的互操作問題>>講得就是跨語言之間的webservice操作！

呵 學(xué)習(xí)學(xué)習(xí)

樓主也混cu？

學(xué)無止境...
關(guān)鍵還是看態(tài)度與思考能力 不在于你掌握了多少 而在于你是否愿意去掌握
很多東西不接觸不知道 一接觸大概很多人也能知道
所以還得看崗位要求 不過對(duì)于基礎(chǔ)的東西 不要求100%知道
但常用的經(jīng)常碰到的問題應(yīng)該知道個(gè)八九不離十吧
但很多問題我還是不知道 碰到以后一google很快也能解決
遇到問題發(fā)現(xiàn)問題解決問題的能力最重要！

我相信好人總有好報(bào).....

mark

小明：
兩邊setting是一樣的。
我的想法和Kevin Lynx差不多，應(yīng)該就是這個(gè)原因吧

megax：
我是一直寫C++的，我沒發(fā)現(xiàn)這樣有什么不對(duì)，臨時(shí)對(duì)象完全可以作為參數(shù)傳遞。
你可能沒有理解doc.Accept()這個(gè)函數(shù)，這不是socket中的accpet，這就是一個(gè)相當(dāng)于打印的函數(shù)，就是一個(gè)過程調(diào)用，doc.accept只在BuildXMLFile內(nèi)調(diào)用，打印完后就銷毀了，然后才是BuildXMLFile調(diào)用過程的結(jié)束。

mark 雙腿膝蓋經(jīng)常疼痛 小腿也經(jīng)常酸痛！

從堆棧中，很顯然是NTDLL new出來的臨時(shí)對(duì)象，被MAPTEST delete時(shí)出錯(cuò)。這也很明顯違背了誰new誰負(fù)責(zé)delete的原則。

我TinyXml版本也是2.5.3 用的vc6.0
我并沒有將TinyXML編譯成lib庫加載調(diào)用，而是將tinyxml的源文件引入工程中，這樣在不同的工程中，就會(huì)受到編譯選項(xiàng)的干擾；并且在我上面描述的接口中就會(huì)出現(xiàn)你所說的對(duì)象的所有權(quán)問題。我將tinyxml編譯成一個(gè)dll供其它工程調(diào)用后，就不會(huì)遇到上面問題。
我沒看TiXmlPrinter的文檔，難道不是上面的原因嗎？

怎么沒人發(fā)表意見？

源碼包怎么那么大？svn上據(jù)說有1.5G，webgc.org上的tar包也有430多M。

不知道這樣的“潛規(guī)則”還有多少？利欲熏心！！！這是一個(gè)不講道德的社會(huì)，不講氣節(jié)的社會(huì)，說到底還是體制的問題。民主不像民主，專制不像專制，這樣下去何去何從？

這可能是你屬性頁顯示范圍太小，調(diào)大顯示范圍即可！

你說的是斷點(diǎn)續(xù)傳的問題，目前l(fā)ibcurl好像并不支持！