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