接上文
《備忘隨筆系列1：MFC與OGRE聯姻注意事項》之后，再記錄一下內存錯誤，經過無數次莫名其妙的內存問題之后，發現一些找不著北的內存Crash問題出現的原因都很荒謬，所以本篇主要例舉一下近期出現的一些怪異內存問題和讓人啼笑皆非的原因所在。
問題1：編譯器在編譯那些訪問成員變量的代碼時算錯了相對于this指針的偏移字節數；賦值給下面一個變量時，卻修改了上面一個變量的值。
原因：與我共事的某位大仙由于酷愛使用結構體傳遞網絡包，所以在某頭文件里用#pragma pack(1)包括住了整個頭文件，一不小心把#include "其他頭文件"那些行也給包括了進去，其中不乏Windows.h stl云云......
解決辦法：當然那個啥......把#pragma pack(1)的位置往下去幾行，還是細心點吧...浪費了整整一天調試。
問題2：從網絡另一端機器發過來一個結構體，分別接收一個結構體中的多個數據成員和一次性接收整個結構體取出的數據不同。
原因：這是個很2的情形，兩個相同的結構體分別在不同的頭文件中，且一個有#pragma pack(1)，一個沒有。
解決辦法：如果要用結構體傳遞網絡包，還是共用頭文件吧......
其實......很多內存問題很不好描述，我也不經常出現如上那樣糾結的問題，所以下面我還是說一個最常見的內存問題（0x.....地址訪問沖突）和原因吧：
“0x.....地址訪問沖突”這個Crash基本上每個人都遇到，而且經常遇到，但是大部分都很容易解決。判斷問題的原因可以看這幾點：
原因1：如果0x....這個值很小，一般就比0大一些，而且是在訪問某對象中的數據成員時出錯的，那么這基本都是因為該對象指針為空，你用了空對象指針調用了代碼。
原因2：如果0x...值同樣很小，但是并非在訪問某對象中的數據成員時出錯，而是調用某函數那一行時出錯的，那么這個函數十有八九是個虛函數，如果我說中的話，那原因應該如前面的原因1相同，只是這回是讀取虛函數表時就崩了。
原因3：如果0x...值類似是0xcdcdcdcd和0xeeeccc或者與這相近的數，且同樣是在訪問數據成員或調用虛函數的時候出的問題，那么這就算是個野指針問題了，釋放了就別再用啊。
原因4：內存越界，這個對程序造成的麻煩比任何麻煩都要大，但是問題并不隱蔽，記得為每個類的數據成員進行必要的初始化。
原因5：使用了memset或ZeroMemory清空一些對象或對象數組。特別是對象數組，很容易讓人忽略這個問題。有些程序員會覺得某對象里都是可以這樣清空的數據成員，所以便這樣做了，但是往往虛函數表指針會被忽略，這個指針絕對不能一起被清空的。
總結：不要讓表達索引的整形在初始化后是個未知值；不要讓指針沒有在初始化時被賦0值；不要不檢查指針的值就拿它訪問成員函數和成員數據；不要重復釋放指針所指對象；不要使用釋放后和未初始化的內存數據；可以的話使用智能指針；釋放指針所指地址后，為指針賦0值；只有在完全是內部類型構成且沒有多態的類型對象上使用memset為對象賦值。