近期寫了一段**，發現有記憶體洩漏，經多次查詢都找不到源點，搞到焦頭爛額，最後經同事細心審查，競是粗心導致的隱藏性錯誤，為了在以後避免犯同樣的錯誤，有必有記錄下來。
在c++中記憶體管理是很重要的，特別是在new 出記憶體後，一定要用到相應的delete釋放記憶體，否則就會出現記憶體洩漏。其實，一般寫**都會有這種意識，但有時自以為是的操作，卻不經意引起記憶體洩漏。
具體情況大體是如下：
在乙個類中
h:class a
private:
int* m_parrdata;
public:
a();
~a():
void function();
cpp:
a::a()
m_parrdata=null;
a::~a()
delete m_parrdata;
void a::function()
m_parrdata=new int[100];
本以為成員變數m_parrdata在類析構函式中釋放記憶體就行了，但實際上這樣做是存在記憶體洩漏風險的，這取決於function()函式呼叫次用，如果只呼叫一次，m_parrdata只分配一次記憶體，當然在物件析構時可以正確釋放記憶體。但是，當function()函式要被多次呼叫，每次呼叫都用申請記憶體，然而m_parrdata只能指向最後一次申請的記憶體位址，物件析構後只會釋放最後一次new出來的記憶體，這樣之前申請的記憶體不但沒有釋放，而且也沒有指引，不能被釋放，一直被占用，直到電腦重啟才會釋放，這樣會告成嚴重的記憶體洩漏。
所以，當用到要new記憶體的指標成員變數時，在成員函式中new記憶體時一定要注意。如上funtion()函式，可以這樣修改：
void a::function()
if(null!=m_parrdata)
m_parrdata=new [100];
或當申請空間大小已知時，直接在建構函式中申請空間，在析構函式中釋放。
IPMI經驗教訓（C記憶體洩露教訓）
乙個由c c 編譯的程式占用的記憶體分為以下幾個部分 棧區 stack 由編譯器自動分配釋放 存放函式的引數值，區域性變數的值等。其操作方式類似於資料結構中的棧。堆區 heap 一般由程式設計師分配釋放，若程式設計師不釋放，程式結束時可能由os 注意它與資料結構中的堆是兩回事，分配方式倒是類似於鍊錶...
c 模組間傳遞引數的一些經驗教訓
最近在開發一套新產品，測試中發現了一些ui奔潰，自己在設計模組通訊介面方面考慮不周全，在此做一下記錄。需求 兩個模組，ui排程模組以及實際功能模組。ui排程模組需要呼叫功能模組，獲取資料，顯示在ui上面。之前的做法 1.在功能模組，資料放在乙個全域性的list或者vector中，匯出list或vec...
有關機器學習的 12 個經驗教訓
這篇文章講述了機器學習研究人員和從業人員總結的 12 個關鍵經驗教訓，包括如何避免陷阱，重點問題以及常見問題的答案。機器學習可以通過一些例子，然後從中歸納出規律來解決重要問題。在手動程式設計 硬編碼 不使用的情況下，這種方法通常是非常有效的，而且非常經濟。隨著更多的資料可以使用，我們可以解決更多雄心...