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