由于書(shū)寫(xiě)習(xí)慣，現(xiàn)在項(xiàng)目里依然使用我原來(lái)習(xí)慣的頭文件定義協(xié)議結(jié)構(gòu)體的方式：
struct EnterLobbyREQ : public ProtocolHeader
{
char mSessionID[64];
}
這種寫(xiě)法比較傳統(tǒng)，有以下優(yōu)點(diǎn)：
- 確實(shí)叫協(xié)議，帶頭文件，如果協(xié)議有修改，客戶端和服務(wù)器代碼馬上能看得出來(lái)
- 可以在結(jié)構(gòu)體里添加一些自動(dòng)填充size,type等的構(gòu)造函數(shù)和一些自動(dòng)計(jì)算變長(zhǎng)包大小的函數(shù)，減少拷貝代碼出現(xiàn)的錯(cuò)誤
- 書(shū)寫(xiě)直觀，初學(xué)者容易理解
但也有以下缺點(diǎn)：
- 一個(gè)修改可能導(dǎo)致全盤(pán)重編
發(fā)送復(fù)雜結(jié)構(gòu)的數(shù)據(jù)不靈活：
如果只想發(fā)送10-20個(gè)成員的結(jié)構(gòu)體里的7，8個(gè)成員，就需要寫(xiě)很多的賦值表達(dá)式，而且這樣的代碼充斥整個(gè)工程
比較流行的寫(xiě)法就是流式寫(xiě)包，在有些工程里叫ProtocolComposer
void Foo (ProtocolComposer& composer)
{
composer << pos << action ;
}
其優(yōu)點(diǎn)顯而易見(jiàn)：
- 協(xié)議可以只是一些注釋，客戶端和服務(wù)器只需要約定俗成就可以，修改協(xié)議無(wú)需重編
- 可以在復(fù)雜結(jié)構(gòu)中自由構(gòu)造發(fā)包內(nèi)容，拷貝復(fù)制方便自如
- 自由制作變長(zhǎng)包及類型決定包內(nèi)容種類等
但其缺點(diǎn)也是有的：
- 一端修改協(xié)議后，另外一端若不及時(shí)修改，在編譯期將無(wú)法發(fā)現(xiàn)，如果最后在運(yùn)行期暫時(shí)沒(méi)有報(bào)錯(cuò)，將形成bug
- 組包速度慢于前者，對(duì)C++類型的代碼支持較好，但是c方式接受較為麻煩
總的來(lái)說(shuō)，后者還是為很多項(xiàng)目所用，所以下一個(gè)項(xiàng)目將啟用后者進(jìn)行編寫(xiě)，希望能得到更好的游戲邏輯編寫(xiě)體驗(yàn)。如果有更好的建議可以回復(fù)。