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