請問下我客戶端調用服務端方法返回-1是為什么？？？
printf("soap error:%d,%s,%s\n", add_soap.error, *soap_faultcode(&add_soap), *soap_faultstring(&add_soap) );
獲取到的錯誤信息都為Null

@lxwei
你用c#寫一個相同的服務，然后比較兩個wsdl文件差異。我覺得這兩個wsdl是有差異的，才導致調用失敗。用http_get返回c#服務生成的wsdl試試。

搜索如：symbol _GetAdaptersInfo@8中的GetAdaptersInfo函數，看看這個函數在哪個庫中。

這個url過來的請求時http_get，你必須自己實現http_get方法，返回wsdl的真正內容即可。

找到這兩個文件添加入工程即可。

很少用QQ，你可以加我msn，謝謝

@張
gsoap guide文檔上有openssl的例子，你可以參考參考。

博主，你好，想和你請教xslt的一些相關知識，我msn:qj-qiujian@sohu.com
,謝謝！

很少用qq，可以加我msn，謝謝！

雖然看過 但是還是感動！
現在社會缺少的就是這樣的錚錚鐵骨！

kick off我一開始也理解錯了 今天查一下才明白 希望大家多分享這些專業詞匯！

mark

俺們的Kbase數據庫也是很牛的!

呵 firefox就該這么折騰...有時間好好向樓主學學

@spyy26224574
include winsock2.h 以及lib

呵 我也是那種比較謙虛謹慎的人 我覺得對于這種群面，很難體現出每個人的真正想法，只能體現出每個人的行為方式，而這實際與實力并無多大關系。特別是當論點比較模糊的時候，謙虛謹慎的人是比較惜言如金的！也許這也是這個社會的悲哀，只要能忽悠！

網上對excel的資料還是很多的 automation方法讀取有比較詳盡的資料。我手頭上剛做過這方面的代碼，對單元格，和并單元格，公式等都支持。
另Excel2007的格式完全變了，是一個openXML的zip包，所以讀取方法完全不一樣了。

soapC.cpp soapH.h soapServer.cpp soapStub.h stdsoap2.cpp stdsoap2.h(stl support)這些文件

可以將所有數據都轉換為字符串的形式進行傳輸，任何數據都可以傳輸的。

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

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

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

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

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

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

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

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

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

可是我們和當年的人比卻缺少太多 信仰 理想 抱負 榮譽與使命.........

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

libevent用于改造網絡模型需要了解哪些知識？

學習了！
不知博主是否真實測試過采用memcached的服務器性能有多少提升？

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

學習！

我這沒有這個問題。
環境:vs2008 vmware6.0.2-build 59824

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

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

記號 學習epoll時好好看看

學習了...不斷積累！

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

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

呵 學習學習

樓主也混cu？

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

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

mark

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

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

mark 雙腿膝蓋經常疼痛 小腿也經常酸痛！

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

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

怎么沒人發表意見？

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

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

這可能是你屬性頁顯示范圍太小，調大顯示范圍即可！

你說的是斷點續傳的問題，目前libcurl好像并不支持！