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