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