控制C++的記憶體分配

長征6號發表於2017-02-08
在嵌入式系統中使用C++的一個常見問題是記憶體分配,即對new 和 delete 操作符的失控。 具有諷刺意味的是,問題的根源卻是C++對記憶體的管理非常的容易而且安全。具體地說,當一個物件被消除時,它的解構函式能夠安全的釋放所分配的記憶體。
這當然是個好事情,但是這種使用的簡單性使得程式設計師們過度使用new 和 delete,而不注意在嵌入式C++環境中的因果關係。並且,在嵌入式系統中,由於記憶體的限制,頻繁的動態分配不定大小的記憶體會引起很大的問題以及堆破碎的風險。

  作為忠告,保守的使用記憶體分配是嵌入式環境中的第一原則。

  但當你必須要使用new 和delete時,你不得不控制C++中的記憶體分配。你需要用一個全域性的new 和delete來代替系統的記憶體分配符,並且一個類一個類的過載new 和delete。

  一個防止堆破碎的通用方法是從不同固定大小的記憶體持中分配不同型別的物件。對每個類過載new 和delete就提供了這樣的控制。

  過載全域性的new 和delete 操作符

可以很容易地過載new 和 delete 操作符,如下所示:

void * operator new(size_t size)
{
void *p = malloc(size);
return (p);
}
void operator delete(void *p);
{
free(p);
}

  這段程式碼可以代替預設的操作符來滿足記憶體分配的請求。出於解釋C++的目的,我們也可以直接呼叫malloc() 和free()。

也可以對單個類的new 和 delete 操作符過載。這是你能靈活的控制物件的記憶體分配。

class TestClass {
public:
void * operator new(size_t size);
void operator delete(void *p);
// .. other members here …
};

void *TestClass::operator new(size_t size)
{
void *p = malloc(size); // Replace this with alternative allocator
return (p);
}
void TestClass::operator delete(void *p)
{
free(p); // Replace this with alternative de-allocator
}

  所有TestClass 物件的記憶體分配都採用這段程式碼。更進一步,任何從TestClass 繼承的類也都採用這一方式,除非它自己也過載了new 和 delete 操作符。通過過載new 和 delete 操作符的方法,你可以自由地採用不同的分配策略,從不同的記憶體池中分配不同的類物件。

  為單個的類過載 new[ ] 和 delete[ ]

必須小心物件陣列的分配。你可能希望呼叫到被你過載過的new 和 delete 操作符,但並不如此。記憶體的請求被定向到全域性的new[ ]和delete[ ] 操作符,而這些記憶體來自於系統堆。

  C++將物件陣列的記憶體分配作為一個單獨的操作,而不同於單個物件的記憶體分配。為了改變這種方式,你同樣需要過載new[ ] 和 delete[ ]操作符。

class TestClass {
public:
void * operator new[ ](size_t size);
void operator delete[ ](void *p);
// .. other members here ..
};
void *TestClass::operator new[ ](size_t size)
{
void *p = malloc(size);
return (p);
}
void TestClass::operator delete[ ](void *p)
{
free(p);
}
int main(void)
{
TestClass *p = new TestClass[10];

// … etc …

delete[ ] p;
}

  但是注意:對於多數C++的實現,new[]操作符中的個數引數是陣列的大小加上額外的儲存物件數目的一些位元組。在你的記憶體分配機制重要考慮的這一點。你應該儘量避免分配物件陣列,從而使你的記憶體分配策略簡單。

專注於企業資訊化,最近對股票資料分析較為感興趣,可免費分享股票個股主力資金實時變化趨勢分析工具,股票交流QQ群:457394862
本文轉自滄海-重慶部落格園部落格,原文連結:http://www.cnblogs.com/omygod/archive/2006/11/08/554573.html,如需轉載請自行聯絡原作者


相關文章