贊。

感覺過于強調(diào)實體，反而讓概念顯得不清楚了，屬于過度抽象。
從現(xiàn)實來講
頻道和聊天者的概念會比較清晰一點。

注入代碼其實無所謂用什么寫，線程有個LPVOID的參數(shù)，把需要的數(shù)據(jù)全部事先寫入遠(yuǎn)程進程，然后把數(shù)據(jù)地址作為參數(shù)傳給遠(yuǎn)程線程就可以了。這樣無需訪問全局變量。

。。。。并不是說用XML不好，或者否定UI樹什么的。

我也是用的MARKUP來建立UI控件樹，并綁定代碼。不過，我是用了一個中間的DOM抽象數(shù)據(jù)層。
這樣，不管外面有什么XML，HTML甚至INI，我只要一個數(shù)據(jù)抽象層放進UI里面就好了。





@Richard Wei

我覺得有幾個問題
1- UI依賴了XML。因為你如果要改變數(shù)據(jù)源，你需要改變UI內(nèi)部的東西。
我做的系統(tǒng)里，用了抽象的DOM數(shù)據(jù)NODE的概念。XML只是建立數(shù)據(jù)NODE的一個源而已。

2- UI的創(chuàng)建很多都用不到。比如prototype這種，如果你想讓你的UI從數(shù)據(jù)上創(chuàng)建，那么你就用一個從數(shù)據(jù)創(chuàng)建就好了。

我的系統(tǒng)里，UI控件的CREATE都是只有統(tǒng)一的一個參數(shù)，IDataNode。這樣接口非常簡單。

文章好，
文字顏色不好。。。。

我用RICHEDIT的WINDOWLESS模式，在codeproject上找到的代碼。
最后事情歸結(jié)為實現(xiàn)一個RTF的生成器，下載了最新的RTF文檔之后，我徹底萎了。

感覺就是MVC。

GOOD, 這個可以有控件用到別的軟件里嗎？

epoll看看 關(guān)系socket
fork看看 關(guān)系啟動服務(wù)和多進程
信號處理看看 關(guān)系錯誤異常
pthread看看 多線程

很好。收藏。

monodevelop以前裝過，菜單文字正常，界面和設(shè)計文字全是亂碼。

很好收藏！

支持，以前從未關(guān)注過高性能磁盤IO。

磁性的柯南。。。看著他變小的長大的我們這一代。

配圖。。。

我最近也在想做個類似的工具
我覺得還可以增加一個東西，就是休息事件的提前通知，然后可以設(shè)置一個便條，記錄下當(dāng)前正在進行的工作，以便于休息后繼續(xù)工作。
我現(xiàn)在想的是輸入一段話，再進入休息狀態(tài)。

good！

@Shannon
142483

GOOD!!!!
鍵盤的，用一個按鍵的狀態(tài)表，記錄當(dāng)前是按下還是抬起。

我能想到的就是細(xì)分區(qū)域的優(yōu)化。

@dynas
玩家位置，在userserver上有記錄。
agent上有客戶端和gameserver建立的繪畫映射，不需要再經(jīng)過userserver中轉(zhuǎn)
@King
純轉(zhuǎn)發(fā)型網(wǎng)管。順帶有加密和解密的工作。

@LOGOS
我是在架構(gòu)上支持HTTP，后臺邏輯服務(wù)可以方便的利用。
你們的運營方還真是照顧呀，哈哈。

感覺上就是一個給你做好基礎(chǔ)引導(dǎo)和保護模式以及中斷調(diào)用等部分，然后讓你用C#寫操作系統(tǒng)邏輯層的一個東西。

應(yīng)該是《操作系統(tǒng)》課程教學(xué)用的吧。

不過不排除以后形成一個完善的操作系統(tǒng)。

你也是做游戲研發(fā)的吧，
服務(wù)器端需要和官方網(wǎng)站的很多WEB系統(tǒng)對接，
如果沒有一個WEB服務(wù)的話，
很多事情都很麻煩。

而且在做頁游的時候，如何將POLICY服務(wù)，和頁面服務(wù)，以及游戲本身的邏輯服務(wù)整合到一起，最終的答案也是所有連接統(tǒng)統(tǒng)使用WEB服務(wù)。

我還是支持加入WEB服務(wù)的做法。
從HTTP到二進制協(xié)議并不難。
考慮到越來越多的WEB整合需求，
TELNET協(xié)議無法滿足需求。

@康

你說的是每個方法最初的理論基礎(chǔ)。但并不是最好的方法。

@楊粼波
目前的方式是用單字節(jié)來表示一個類型。
類型有 int, uint, float, string

int, uint, float 又有數(shù)組類型。

string和array是帶16位的Length字段。

array除了1字節(jié)的array類型指定，還帶一個1字節(jié)的元素數(shù)據(jù)類型。


對整體容量的增加，有限。

不過，現(xiàn)在這種方式并不是最好的方式。

我認(rèn)為的最好的方式，所有類型都提取成一個數(shù)據(jù)類型對象，也就是類似GOOGLE PROTOCOL BUFFER的用額外的描述生成的一個對結(jié)構(gòu)體的描述。這個方式是跟我的數(shù)據(jù)對象和映射的整體邏輯架構(gòu)相關(guān)的。目標(biāo)是實現(xiàn)服務(wù)器端，在對所有數(shù)據(jù)和邏輯的描述上形成的整體架構(gòu)的統(tǒng)一，同時將類型和表義信息從最終數(shù)據(jù)存儲中去掉。

不過這種情況下，可能會出現(xiàn)版本問題，由于雙方描述的版本差異，導(dǎo)致兼容性問題。我的解決方法，是把原有的類型信息，更換為FIELDINDEX信息，也就是字段索引。在結(jié)構(gòu)體描述的更改過程中，遵循字段出現(xiàn)增加，就增長其FIELDINDEX的原則。這樣，在有限的版本空間內(nèi)，F(xiàn)IELDINDEX會精確對應(yīng)到相應(yīng)的字段上。如果FIELDINDEX超出值域限制，那只有放到新的結(jié)構(gòu)描述中去了。

我在網(wǎng)絡(luò)封包這塊，有著很長的一個摸索過程，大概經(jīng)歷過以下幾個階段：
1- 結(jié)構(gòu)體直接作為封包發(fā)送
2- 結(jié)構(gòu)體序列化（封包內(nèi)只有數(shù)據(jù)本身，手動編寫序列化和反序列化的方法）
3- 結(jié)構(gòu)體序列化（封包內(nèi)帶有類型信息，手動編寫序列化和反序列化的方法）
4- 數(shù)據(jù)對象和數(shù)據(jù)映射（封包內(nèi)帶有字段信息，通過數(shù)據(jù)映射來序列化和反序列化）

這樣做有個好處是不需要定型的struct，處理過程只要傳入一個復(fù)合類型value的數(shù)組即可，對于統(tǒng)一整體架構(gòu)，減少代碼工作量很有幫助。

我使用的是類型加數(shù)值的序列化和反序列化，封包不僅用于網(wǎng)絡(luò)，還用于db，內(nèi)部消息等地方。

@康
我這里也是這種方法，不過，這里是在解決另外的問題：

當(dāng)一個角色有多個可見區(qū)域的時候，
可見區(qū)域重疊，帶來的廣播消息的重復(fù)。

@戰(zhàn)魂小筑
我覺得異常在新一代的語言里是用來進行錯誤處理的。
所以異常在我這個體系里是作為一種像是錯誤編號一樣的數(shù)據(jù)對象存在，
能夠被捕捉到，并由映射進行處理。

@Kevin Lynx
數(shù)據(jù)也腳本化，我感覺不合適。

我是要提供可視化編輯工具給策劃，讓他們自己去設(shè)計數(shù)據(jù)對象。

腳本這些粗活，就是服務(wù)器程序來做。

所有工具都做成各種PAD可部署的，這樣就不用限制辦公地點和時間了。

隨時隨地做事。

有個好的點子可以立即應(yīng)用到實際的游戲服務(wù)中去。

@Kevin Lynx
配置+腳本共同的
每個都可以實時修改
這樣該錯誤，更新什么的，根本不用重啟了

服務(wù)器本身的程序就是一堆底層的庫在那里

然后就是支持這些數(shù)據(jù)對象和映射。

數(shù)據(jù)對象雖然看起來很復(fù)雜，實際上是個簡單功能的容器類，和封包的結(jié)構(gòu)很像。

大部分的事情都是在映射里做的。而這些映射都是腳本的。


腳本我準(zhǔn)備用quartz composer那種卡片式的，這樣可以用IPAD，GPAD，樂PAD等各種PAD，用3G卡在某個公園的角落里摸幾下就把服務(wù)器BUG給修改好了。

接著我在那邊跟你說的，我是不允許代碼和腳本碰數(shù)據(jù)對象的屬性的。

屬性必須由對象設(shè)計器生成。這個對象設(shè)計器是在線的，也就是運行時創(chuàng)建，更改的。

映射也是，映射說起來就是一種腳本，用來關(guān)聯(lián)對象之間的屬性的東西。

你那個獨立博客在CHROME上會標(biāo)紅標(biāo)骷髏頭。

多重繼承真的是個很大的坑。
要小心翼翼的通過。
我以前也是和你一樣的用VOID*的時候出了這個問題。

@臥槽
是的，我確實是個菜鳥。

@megax
Vb的數(shù)據(jù)庫部分沒用過，不清楚
不過c++里面數(shù)據(jù)庫的orm不是很好實現(xiàn)，也沒有很多好的庫。
另外是效率和異步考慮，數(shù)據(jù)庫操作必須可控
還有必要的靈活性
所以使用了存儲過程和連接線程池

不過，我找到一個新的方法來降低邏輯層的數(shù)據(jù)庫相關(guān)復(fù)雜度。也是類似對象關(guān)系映射，我的方法是根據(jù)對象生成一個字段模型（字段偏移和類型表），這個作為映射中心，網(wǎng)絡(luò)封包、數(shù)據(jù)庫表作為映射源和目標(biāo)。字段模型可外部編輯并從模型生成實體。

然后底層還是這種連接池。

我沒看過《beautiful code》，我不全相信書
我只說自己的想法，我不引經(jīng)據(jù)典
我的回復(fù)就是表達我的態(tài)度，
我不逃避
我為我每條回復(fù)負(fù)責(zé)
我不想打嘴仗
我認(rèn)為自己很淺薄
我就是飯中淹。

我也想說句“臥槽”。

耗時很少，這個描述不是很精確。

首先確定你的負(fù)載到底是什么，CPU，內(nèi)存，還是網(wǎng)絡(luò)IO。
然后量化并監(jiān)控你的負(fù)載情況，并集中進行管理。
最后，根據(jù)你集中管理的量化的負(fù)載情況，分配新到來的用戶的接入點。

這個GUI框架挺好的
我是保留WPARAM和LPARAM
不過一些常用的消息，做進了內(nèi)部邏輯了。比如onpaint這種，在這個內(nèi)部邏輯里，PARAM就被轉(zhuǎn)換成真實的變量了，比如HDC這樣的。

另外，我直接用VS的DIALOG編輯器，編輯成無窗口模式，然后用一個FORM套住這個無窗口模式的DIALOG，就間接實現(xiàn)了界面的所見即所得編輯。

用法，無所謂。可用就行。

不錯，深有同感。
不過自己做庫，也有個很嚴(yán)重的問題，要想突破自己，也是比較困難的。
我自己維護了一個類似STL的庫，一個網(wǎng)絡(luò)庫，還有很多雜七雜八的東西。很多次重構(gòu)之后，很多架構(gòu)依然還存在著，只是不斷的修修補補。有時候想推翻重來，卻總是因為各種原因而放棄或者失敗了。
可能做項目的時候，不適合去做庫的推翻重來。
不過有時候做項目時，偶爾會來一些靈感，突然獲得一個能夠推翻之前庫里的東西的想法，但是卻遲遲無法更新到庫里面。因為心里在害怕，沒有大量測試的代碼，會導(dǎo)致庫的不穩(wěn)定。

為什么不把pointer和counter放在一個結(jié)構(gòu)里，new這個結(jié)構(gòu)？
我做這個東西的時候，就是做這樣一個core_struct，然后加一個core_struct池來維護內(nèi)存。所有的Ptr傳遞和保存的就是這個core_struct的指針。

頂
另外,文件分配表的位置最好放在包末尾，這樣就沒有數(shù)量限制了，也不用預(yù)留empty_tags。

微軟的操作系統(tǒng)有開源。可以去找來看。

@Θ§奏之章℡
參閱和真正需求到的，完全不一樣。