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

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

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

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

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

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

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

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

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

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

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

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

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

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

學(xué)習(xí)！

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

呵呵 編譯openvpn的時候需要編譯openssl 剛編譯過！

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

記號 學(xué)習(xí)epoll時好好看看

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

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

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

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

樓主也混cu？

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

我相信好人總有好報.....

mark

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

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

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

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

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

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

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

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

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

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