記憶體管理方式

遊戲服務端的工作主要就是實時的處理使用者的邏輯，存取，大量資料包的收發，這其中，網路因素是一個重要的原因，這個東西無法避免，但是更重要的是程式內部的運作方式，通常我們知道，程式中最耗資源與硬體的不是程式的執行和操作，主要是記憶體和資源的頻繁切換，讓CPU和記憶體一直在忙。其實就是 new/delete的問題，他們一般都是用來申請小塊記憶體的，長時間申請問造成記憶體出現碎片，從而導致機器效能下降，對伺服器程式來說，響應速度像生命一樣，所以，傳統的記憶體管理方式就行不通了。

為了避免使用new/delete帶來的問題，一般採用兩種方法：

1.從一開始就是用靜態分配記憶體後再使用，我們知道，靜態記憶體申請後會在程式執行時一直使用，不會釋放，只能改變其中存的資料，這樣就避免了大量的申請與釋放記憶體的操作。

2.使用MemoryPool(記憶體池)，這塊的記憶體池得自己寫，一般的遊戲中都有自己單獨寫的記憶體池程式碼，這個後面再說。

在製作伺服器程式，這兩種都有使用，不過大塊的記憶體基本都是使用MemoryPool，小塊且區域性記憶體基本使用靜態記憶體。

型別的問題

這塊的東西主要是個人習慣問題，如果有優良的程式設計習慣，一般沒什麼問題。特別是像型別轉化與typedef的時候需要注意一下。

Const的使用

其實我覺得這個問題我不應該多說，該用的地方用就行了，不過很多人就吃虧在這個const上了，這個東西用多了就熟悉了，多用幾次，肯定會熟練的。主要是看清楚const的位置，它是將這個常屬性加在了那個部分，這樣基本就沒有什麼問題了。

型別轉化的方法

一般的資料型別轉化的方法，基本都是強制轉化，不過這樣某些時候會帶來一些非確定的問題。一般是基本資料型別可以直接強轉型別，繼承類物件之間可以強轉型別，轉化方式大家都很清楚,如下：

(Type*)SourceType // Type 為要轉為的型別,SourceType為原來要轉的物件

型別轉化還存在以下四種轉化方式，

dynamic_cast 主要是在相互間有繼承關係的物件指標或者引用之間做型別轉化的時候經常使用到。一般(type*)強轉型別就是使用dynamic_cast

static_cast 只是邏輯上的功能型別轉換，大部分用在繼承關係的指標型別轉換

reinterpret_cast 他是一種沒有任何限制的型別的轉換，從任何型別可以轉化到任何型別，不過這個時候，編譯器就不負任何責任了。如果你願意使用，就使用吧。

const_cast 主要用於將const常量轉換為non-const型別

其他的一些功能大家去網上搜下，說的肯定更詳細。我就不做贅述了。

希望大家喜歡，有問題，歡迎指正和補充.