#
錯(cuò)誤碼很重要，可以由此判斷網(wǎng)絡(luò)連接到底發(fā)生了神馬事情，從而驅(qū)動(dòng)高層邏輯的行為。只有籠統(tǒng)的錯(cuò)誤碼判斷的網(wǎng)絡(luò)層是不夠規(guī)范的，鄙人覺得有些錯(cuò)誤碼還是需要在網(wǎng)絡(luò)層就區(qū)分開的，特此記錄一些當(dāng)前實(shí)驗(yàn)的錯(cuò)誤碼以及發(fā)生原因。
以下是一部分在async_receive()的handler處捕獲到的比較有用的錯(cuò)誤碼
| 錯(cuò)誤碼（十進(jìn)制） |
枚舉 |
發(fā)現(xiàn)原因 |
| 10009 |
boost::asio::error::bad_descriptor |
在一個(gè)已經(jīng)關(guān)閉了的套接字上執(zhí)行async_receive() |
| 995 |
boost::asio::error::operation_aborted |
正在async_receive()異步任務(wù)等待時(shí)，本端關(guān)閉套接字 |
| 10054 |
boost::asio::error::connection_reset |
正在async_receive()異步任務(wù)等待時(shí)，遠(yuǎn)端的TCP協(xié)議層發(fā)送RESET終止鏈接，暴力關(guān)閉套接字。常常發(fā)生于遠(yuǎn)端進(jìn)程強(qiáng)制關(guān)閉時(shí)，操作系統(tǒng)釋放套接字資源。 |
| 2 |
boost::asio::error::eof |
正在async_receive()異步任務(wù)等待時(shí)，遠(yuǎn)端關(guān)閉套接字，這里跟10054發(fā)生的情況似乎一樣，但是實(shí)際上應(yīng)該是有區(qū)別的，具體神馬區(qū)別，由回復(fù)中jack的說法，這個(gè)是遠(yuǎn)端正常關(guān)閉套接字。 |
只是一些淺陋的測試，目前覺得有用的也就是這幾個(gè)，不正確的地方請(qǐng)送我雞蛋。
前面必須使用到的，類似下面的指令
F:\sdk\boost>bjam --link=static --threading=multi --runtime-link=shared debug release stage
后面需要選擇編譯器和要編譯的庫
--toolset=msvc-9.0 --with-date_time --with-thread......
這兩個(gè)東西在一起問題真呀么多......前些日子才寫的一個(gè)注意事項(xiàng)的隨筆，這回又有問題需要記錄，好吧，開新文寫。
問題：由于項(xiàng)目的復(fù)雜度，問題的表現(xiàn)與原因其實(shí)相差十萬八千里。
原因：MFC在打開和保持文件后（即打開CFileDialog對(duì)話框后），就會(huì)修改進(jìn)程的當(dāng)前目錄，就是SetCurrentDirectoy()，導(dǎo)致OGRE里那些用相對(duì)路徑做Location的資源目錄下的文件全部無法讀取（其實(shí)我覺得OGRE應(yīng)該把這些相對(duì)目錄在讀取文件的時(shí)候換成絕對(duì)目錄）。具體就是openResource()中調(diào)用stat()出錯(cuò)，文件系統(tǒng)中找不到指定文件。
解決方法：在合適的地方調(diào)用SetCurrentDirectoy()把進(jìn)程當(dāng)前目錄設(shè)置回進(jìn)程工作目錄吧......
于是又是一下午+半個(gè)晚上的調(diào)試時(shí)間......
接上文
《備忘隨筆系列1：MFC與OGRE聯(lián)姻注意事項(xiàng)》之后，再記錄一下內(nèi)存錯(cuò)誤，經(jīng)過無數(shù)次莫名其妙的內(nèi)存問題之后，發(fā)現(xiàn)一些找不著北的內(nèi)存Crash問題出現(xiàn)的原因都很荒謬，所以本篇主要例舉一下近期出現(xiàn)的一些怪異內(nèi)存問題和讓人啼笑皆非的原因所在。
問題1：編譯器在編譯那些訪問成員變量的代碼時(shí)算錯(cuò)了相對(duì)于this指針的偏移字節(jié)數(shù)；賦值給下面一個(gè)變量時(shí)，卻修改了上面一個(gè)變量的值。
原因：與我共事的某位大仙由于酷愛使用結(jié)構(gòu)體傳遞網(wǎng)絡(luò)包，所以在某頭文件里用#pragma pack(1)包括住了整個(gè)頭文件，一不小心把#include "其他頭文件"那些行也給包括了進(jìn)去，其中不乏Windows.h stl云云......
解決辦法：當(dāng)然那個(gè)啥......把#pragma pack(1)的位置往下去幾行，還是細(xì)心點(diǎn)吧...浪費(fèi)了整整一天調(diào)試。
問題2：從網(wǎng)絡(luò)另一端機(jī)器發(fā)過來一個(gè)結(jié)構(gòu)體，分別接收一個(gè)結(jié)構(gòu)體中的多個(gè)數(shù)據(jù)成員和一次性接收整個(gè)結(jié)構(gòu)體取出的數(shù)據(jù)不同。
原因：這是個(gè)很2的情形，兩個(gè)相同的結(jié)構(gòu)體分別在不同的頭文件中，且一個(gè)有#pragma pack(1)，一個(gè)沒有。
解決辦法：如果要用結(jié)構(gòu)體傳遞網(wǎng)絡(luò)包，還是共用頭文件吧......
其實(shí)......很多內(nèi)存問題很不好描述，我也不經(jīng)常出現(xiàn)如上那樣糾結(jié)的問題，所以下面我還是說一個(gè)最常見的內(nèi)存問題（0x.....地址訪問沖突）和原因吧：
“0x.....地址訪問沖突”這個(gè)Crash基本上每個(gè)人都遇到，而且經(jīng)常遇到，但是大部分都很容易解決。判斷問題的原因可以看這幾點(diǎn)：
原因1：如果0x....這個(gè)值很小，一般就比0大一些，而且是在訪問某對(duì)象中的數(shù)據(jù)成員時(shí)出錯(cuò)的，那么這基本都是因?yàn)樵搶?duì)象指針為空，你用了空對(duì)象指針調(diào)用了代碼。
原因2：如果0x...值同樣很小，但是并非在訪問某對(duì)象中的數(shù)據(jù)成員時(shí)出錯(cuò)，而是調(diào)用某函數(shù)那一行時(shí)出錯(cuò)的，那么這個(gè)函數(shù)十有八九是個(gè)虛函數(shù)，如果我說中的話，那原因應(yīng)該如前面的原因1相同，只是這回是讀取虛函數(shù)表時(shí)就崩了。
原因3：如果0x...值類似是0xcdcdcdcd和0xeeeccc或者與這相近的數(shù)，且同樣是在訪問數(shù)據(jù)成員或調(diào)用虛函數(shù)的時(shí)候出的問題，那么這就算是個(gè)野指針問題了，釋放了就別再用啊。
原因4：內(nèi)存越界，這個(gè)對(duì)程序造成的麻煩比任何麻煩都要大，但是問題并不隱蔽，記得為每個(gè)類的數(shù)據(jù)成員進(jìn)行必要的初始化。
原因5：使用了memset或ZeroMemory清空一些對(duì)象或?qū)ο髷?shù)組。特別是對(duì)象數(shù)組，很容易讓人忽略這個(gè)問題。有些程序員會(huì)覺得某對(duì)象里都是可以這樣清空的數(shù)據(jù)成員，所以便這樣做了，但是往往虛函數(shù)表指針會(huì)被忽略，這個(gè)指針絕對(duì)不能一起被清空的。
總結(jié)：不要讓表達(dá)索引的整形在初始化后是個(gè)未知值；不要讓指針沒有在初始化時(shí)被賦0值；不要不檢查指針的值就拿它訪問成員函數(shù)和成員數(shù)據(jù)；不要重復(fù)釋放指針?biāo)笇?duì)象；不要使用釋放后和未初始化的內(nèi)存數(shù)據(jù)；可以的話使用智能指針；釋放指針?biāo)傅刂泛螅瑸橹羔樫x0值；只有在完全是內(nèi)部類型構(gòu)成且沒有多態(tài)的類型對(duì)象上使用memset為對(duì)象賦值。
細(xì)節(jié)決定那啥來著，一些細(xì)節(jié)雖然不是什么難事，但是一旦卡住總是會(huì)很煩心，需要太多時(shí)間去調(diào)試，耽誤的是寶貴的項(xiàng)目進(jìn)度，所以我將在這里把一些總結(jié)貼出來，愿能給國內(nèi)的游戲技術(shù)圈同僚們一點(diǎn)小幫助，節(jié)約寶貴的時(shí)間，畢竟總是在網(wǎng)絡(luò)上攝取營養(yǎng)，算是回報(bào)社會(huì)吧。
本文記錄最近發(fā)現(xiàn)的一些 MFC 和 OGRE1.7.2版本 聯(lián)姻的注意事項(xiàng)：
問題1：創(chuàng)建Ogre的CView窗口后，無法截獲鼠標(biāo)點(diǎn)擊和移動(dòng)信息，只能獲取鼠標(biāo)滾輪信息。
原因及解決方案：傳遞CView窗口句柄時(shí)，請(qǐng)一定使用externedWindowHandle的屬性key，切記不要使用parentWindowHandle，因?yàn)閜arentWindowHandle是讓CView成為渲染窗口的父窗口，鼠標(biāo)鍵盤消息都不會(huì)路由到CView上，而是在渲染窗口里被截獲；而externedWindowHandle是讓CView窗口本身成為渲染窗口，所以CView才能正常截獲到輸入消息。
問題2：當(dāng)解決問題1之后，發(fā)現(xiàn)使用externedWindowHandle繪制出的窗口很小，而使用parentWindowHandle時(shí)則正常
原因及解決方案：注意繼承CView::OnSize()函數(shù)響應(yīng)WM_SIZE消息，但請(qǐng)切記：千萬別在OnSize中調(diào)用Ogre::RenderWindow::resize()函數(shù)，這會(huì)導(dǎo)致OnSize()函數(shù)的遞歸回調(diào)，因?yàn)镺gre::RenderWindow::resize()函數(shù)中會(huì)調(diào)用AdjustWindow()和SetWindowPos()函數(shù)，這會(huì)導(dǎo)致發(fā)送WM_SIZE消息并縮小窗口，從而導(dǎo)致問題的發(fā)生。
問題3：如何解決窗口重置大小的問題
解決方案：在OnSize()中
不能調(diào)用Ogre::RenderWindow::resize()函數(shù)，而
應(yīng)該調(diào)用Ogre::RenderWindow::windowMovedOrResized()函數(shù)，通知RenderWindow在渲染前重新設(shè)置Viewport的寬高比例。
問題4：怎樣確保主渲染循環(huán)
分析：上網(wǎng)看了一些相關(guān)的解決方案，發(fā)現(xiàn)大多使用WM_TIMER消息來維持OGRE的主渲染循環(huán)，這應(yīng)該是下下策的方案了吧......當(dāng)然還有其他的實(shí)現(xiàn)方案，譬如開另一個(gè)線程，這個(gè)方法還是可行的，但是總有些不對(duì)味，因?yàn)殇秩久髅鲬?yīng)該在主線程中才是最佳方案。于是我就看了一下MFC閑下來的時(shí)候都干了些什么，最后發(fā)現(xiàn)了以下解決方案，應(yīng)該算是很不錯(cuò)但并不難的解決辦法了，為什么沒見網(wǎng)上有人提供這樣的方案讓我很不理解，窩著藏著也得不到半點(diǎn)好處：
解決方案：使用空閑回調(diào)。該回調(diào)是需要繼承CWinApp::OnIdle()函數(shù)（好像是叫這個(gè)，反正肯定帶Idle這個(gè)單詞），當(dāng)主線程中的消息循環(huán)沒有取到消息時(shí)（調(diào)用PeekMessage()沒有獲取到消息），就會(huì)去調(diào)用這個(gè)函數(shù)，于是......就在這個(gè)函數(shù)里調(diào)用繪制一幀吧：Ogre::RenderWindow::update()，另外有動(dòng)畫的話還需要調(diào)用Ogre::Root::_fireFrameRenderingQueued()，因?yàn)閯?dòng)畫更新在這里。如果是想讓所有渲染對(duì)象都更新一幀的話，直接調(diào)用Ogre::Root::renderOneFrame()吧。
解決方案不一定最好，也不一定適合你的情況，但愿能盡微薄之力，也是作為我個(gè)人的備忘吧。
最近在給公司里碼一個(gè)場景編輯器，大致得實(shí)現(xiàn)的功能有：
地形高度刷
地形紋理刷
放置小物件和房屋
放置粒子系統(tǒng)
設(shè)置路徑點(diǎn)和只能攝像機(jī)點(diǎn)
算是個(gè)簡單的不能再簡單的場景編輯器了吧...但是這樣的一個(gè)工具還是很頭痛的，特別是用C++來寫...
頭痛的原因不是別的，正是這個(gè)表現(xiàn)層和后臺(tái)數(shù)據(jù)同步問題。這個(gè)在C++的UI庫中目前還真沒有什么現(xiàn)成的好辦法，于是開始造輪子，為MFC寫了PropertySet和OperatorStack。
首先這個(gè)UI數(shù)據(jù)和內(nèi)存數(shù)據(jù)雙向同步的問題直接讓我崩潰了...由于以前寫過一些工具，知道這東西如果不做個(gè)設(shè)計(jì)就開始沖著功能寫的話會(huì)有什么后果。嗯，于是繼承封裝了CMFCPropertyGridCtrl控件，為每個(gè)葉子屬性項(xiàng)封裝了一個(gè)LeafItem，根據(jù)屬性名來更新PropertySet里對(duì)應(yīng)的數(shù)據(jù)......具體實(shí)現(xiàn)幾千字略- - 最終成型時(shí)代碼這樣：
DynamicObject obj;
propertyGrid.attachObject(obj);
這里的DynamicObject繼承PropertySet，于是propertyGrid控件就會(huì)顯示obj里所有的屬性數(shù)據(jù)了...然后是雙向更新問題，目前是給Property里加了一個(gè)eventValueChanged事件響應(yīng)，讓PropertyGridCtrl監(jiān)聽這些數(shù)據(jù)的變化，而propertyGridCtrl這個(gè)UI上的數(shù)據(jù)變化同樣是派生實(shí)現(xiàn)CMFCPropertyGridCtrl的值變化響應(yīng)函數(shù)來給綁定的LeafItem更新數(shù)據(jù)，也是直接就刷新到Property里了。
還有OperatorStack.....這個(gè)是操作棧，記錄用戶操作的，用于撤銷和重做的操作，也用到了PropertySet來記錄變化對(duì)象的屬性快照，嗯，叫SnapShootRecord的類里面記錄的都是一個(gè)對(duì)象的變化屬性。
先就記錄這么多，很亂很不容易懂，主要給我自己做個(gè)記錄的，沒啥貢獻(xiàn)，實(shí)際上還有很多不好用的地方，所以最近在想一些改進(jìn)設(shè)計(jì)，等我想好了放上來詳細(xì)設(shè)計(jì)和源碼吧.......
實(shí)現(xiàn)的目的是為了在一些特定情況下不去使用boost的filter_streambuf，不使用boost::iostreams的理由如下：
1、基于運(yùn)行時(shí)配置的過濾器，效率稍低
2、對(duì)于網(wǎng)絡(luò)通訊而言，boost的filter_streambuf乃至整個(gè)iostreams庫都顯得較為臃腫。
所以，我自己編寫了一套filter_streambuf，繼承了std::streambuf，并配合自己重新設(shè)計(jì)的archive和batch_data進(jìn)行網(wǎng)絡(luò)通訊，無論是效率還是易用性上都超出使用boost的iostreams。而boost的那套東西經(jīng)過我的反復(fù)使用后，覺得更適合用在文件讀寫和數(shù)據(jù)持久化上。
如果要說哪里不如boost的filter_stream，也就是boost的filter_streambuf可以動(dòng)態(tài)配置filter，而我使用的是模板技術(shù)將filter的關(guān)系在編譯期就關(guān)聯(lián)了起來，所以只能是靜態(tài)配置filter。下面是具體使用時(shí)的完整例子代碼：
1 #include <ccs/util/ios/ifilter_streambuf.hpp>
2 #include <ccs/util/ios/ofilter_streambuf.hpp>
3 #include <ccs/util/ios/memory_terminal.hpp>
4
5 using namespace ccs;
6 using namespace util;
7
8 // 輸出過濾
9 struct my_ofilter
10 {
11 typedef ios::ofilter_tag tag_type;
12
13 template<typename OutT>
14 std::streamsize write(const char* p, std::streamsize n, OutT& _out)
15 {
16 std::streamsize i = 0;
17 for (; i < n; ++i)
18 {
19 char c = p[i];
20 if (_out.write(&++c, 1) != 1)
21 break;
22 }
23 return i;
24 }
25 };
26
27 // 輸入過濾
28 struct my_ifilter
29 {
30 typedef ios::ifilter_tag tag_type;
31
32 template<typename InT>
33 std::streamsize read(char* p, std::streamsize n, InT& _in)
34 {
35 std::streamsize i = 0;
36 for (; i < n; ++i)
37 {
38 char c;
39 if (_in.read(&c, 1) != 1)
40 break;
41 p[i] = --c;
42 }
43 return i;
44 }
45 };
46
47 // 輸出內(nèi)存設(shè)備
48 struct memory_odevice
49 {
50 typedef ios::dest_tag tag_type;
51
52 std::streamsize write(const char* p, std::streamsize n, ios::memory_oterminal& _out)
53 {
54 return _out.write(p, n);
55 }
56 };
57
58 // 輸入內(nèi)存設(shè)備
59 struct memory_idevice
60 {
61 typedef ios::source_tag tag_type;
62
63 std::streamsize read(char* p, std::streamsize n, ios::memory_iterminal& _in)
64 {
65 return _in.read(p, n);
66 }
67 };
68
69
70 int main(int _Argc, char** _Args)
71 {
72 char buf[256];
73 ios::memory_oterminal memout(buf, 256);
74 ios::memory_iterminal memin(buf, 256);
75 ios::ifilter_streambuf<ios::memory_iterminal, mpl::list2<my_ifilter, memory_idevice> > insbuf(&memin);
76 ios::ofilter_streambuf<ios::memory_oterminal, mpl::list2<my_ofilter, memory_odevice> > outsbuf(&memout);
77 std::istream is(&insbuf);
78 std::ostream os(&outsbuf);
79
80 int num = 188;
81 os.write((char*)&num, sizeof(int));
82 os.flush();
83 is.read((char*)&num, sizeof(int));
84
85 std::cout << num << std::endl;
86 system("pause");
87 }
代碼中的意思就是將寫入的數(shù)據(jù)逐字節(jié)的加1，并保存在內(nèi)存緩沖里，然后又從內(nèi)存緩沖中讀出，逐字節(jié)減1，并輸出到控制臺(tái)，一套經(jīng)過過濾的讀寫流便完成了。由于使用了模板元的list作為鏈接，在release模式下所有的過濾器操作都是內(nèi)聯(lián)的，這雖然也是我預(yù)想的效果，但看完匯編碼之后，著實(shí)讓我高興了一晚上，這種成就感真的是programer最大的樂趣。
需要說明的是：代碼中的mpl::list2是自己實(shí)現(xiàn)的模板元鏈表...過段時(shí)間考慮研究一下boost的并替換過來，因?yàn)槟莻€(gè)list后面的2讓我覺得很不夠智能...當(dāng)然，如果boost的list實(shí)現(xiàn)過于復(fù)雜，或是不能讓我的代碼完全內(nèi)聯(lián)化的話，肯定不會(huì)考慮使用。
完成這個(gè)之后，我便準(zhǔn)備著手構(gòu)建cge項(xiàng)目，所謂的cge，就是cloud game engine的縮寫...顧名思義就是使用了云技術(shù)的游戲引擎，我想在業(yè)余時(shí)間嘗試一些顛覆傳統(tǒng)cs架構(gòu)的在線游戲引擎架構(gòu)設(shè)計(jì)，具體難點(diǎn)估計(jì)會(huì)有2個(gè)：
1、運(yùn)用gpgpu group的并行運(yùn)算技術(shù)，考慮使用目前市場占用率最大的nvidia tesla服務(wù)器配合cuda，在服務(wù)器用physX實(shí)現(xiàn)一定的物理模擬。
2、在即時(shí)性較強(qiáng)的在線游戲中，ping值一直是最大的挑戰(zhàn)，所以有選擇性的使用云計(jì)算技術(shù)，這是架構(gòu)設(shè)計(jì)上的挑戰(zhàn)。
關(guān)于cge的設(shè)計(jì)思考和規(guī)劃，會(huì)另外開貼具體闡述，并記錄開發(fā)進(jìn)度和情況。
記錄一下這個(gè)，容易忘記的DXSDK_DIR環(huán)境變量，可以在cmake里添加dx的sdk路徑，否則找死也找不到rendersystem_direct3d的項(xiàng)目文件。
今天記錄一下長久以來屢次犯的錯(cuò)，每次都是換一種方法編碼來繞過這個(gè)問題實(shí)現(xiàn)功能的，因?yàn)檫@個(gè)問題太過隱蔽，導(dǎo)致今天才發(fā)現(xiàn)其中真正的原因...下面進(jìn)行問題描述：
1
std::map<std::string, Value> keyValue; // 在函數(shù)內(nèi)部分配的堆棧對(duì)象（局部變量）
2ReadData(keyValue);// 從dll中導(dǎo)出的函數(shù)
3keyValue.clear(); // delete中出現(xiàn)assert異常
第一行是在應(yīng)用程序中的堆棧中分配的內(nèi)存空間。
第二行是我自己寫的dll庫，用來讀取一些數(shù)據(jù)加入到keyValue中。
第三行是清空keyValue，其實(shí)如果不寫這一行的話，keyValue也會(huì)在函數(shù)結(jié)尾時(shí)清空，到那時(shí)同樣會(huì)出現(xiàn)錯(cuò)誤。
這一切乍一看沒啥問題，keyValue是局部變量，為什么局部變量的釋放會(huì)出現(xiàn)異常錯(cuò)誤呢？這是因?yàn)榈诙蠷eadData的緣故。ReadData的邏輯在另外一個(gè)可執(zhí)行模塊中，在其中分配的內(nèi)存空間不一定與當(dāng)前模塊在同一個(gè)堆區(qū)。
我們知道，std::map是一個(gè)樹結(jié)構(gòu)的容器，我在ReadData內(nèi)部往keyValue中添加了數(shù)據(jù)，keyValue中會(huì)在堆區(qū)中分配樹節(jié)點(diǎn)，而這個(gè)節(jié)點(diǎn)將會(huì)在當(dāng)前模塊在keyValue的析構(gòu)中被釋放。也就是說，我無意中在dll模塊中分配了堆空間，又無意中在exe模塊中企圖釋放該空間，這樣的行為導(dǎo)致錯(cuò)誤是不足為怪的。
時(shí)刻牢記，在一個(gè)模塊中分配和釋放同一塊內(nèi)存區(qū)域，警惕你所看不見的內(nèi)存分配和釋放。
好久沒寫blog了，這次初步完成了一個(gè)文檔化的網(wǎng)絡(luò)流框架，這玩意兒是咱自己這樣叫，但具體是啥玩意兒呢？其實(shí)就是將網(wǎng)絡(luò)通訊數(shù)據(jù)結(jié)構(gòu)給串行化到緩沖里，再發(fā)送到網(wǎng)絡(luò)的另一端，由另一端再串行化到相應(yīng)的類型對(duì)象里。恩，這聽起來沒啥難度呀，但事實(shí)并非如此，呵呵，該架構(gòu)建立在asio基礎(chǔ)之上，目前完成了tcp通訊部分，基本可以很方便的使用了。
為啥我要寫這么個(gè)架子，因?yàn)榫W(wǎng)絡(luò)通訊需要考慮很多情況，如粘包、未接收完整、緩沖不夠大等情況，而且在項(xiàng)目開發(fā)過程中，不斷的添加和修改一些通信協(xié)議相關(guān)的數(shù)據(jù)包結(jié)構(gòu)。為了讓程序員不要管那么多麻煩的情況，同時(shí)易于修改和添加新的通訊協(xié)議，于是就寫了這么個(gè)架構(gòu)，不過今天比較忙，還是下次傳上用例代碼吧，源碼可能會(huì)在不久以后發(fā)布的通用庫模板庫里找到。
恩，咱要發(fā)布自己的一個(gè)開源庫，建立在stl和boost基礎(chǔ)上，可跨平臺(tái)編譯 0 0......
到時(shí)候再說了。