C 和 C++ 程序中的內存錯誤非常有害：它們很常見，並且可能導致嚴重的後果。來自計算機應急響應小組（請參見參考資料）和供應商的許多最嚴重的安全公告都是由簡單的內存錯誤造成的。自從 70 年代末期以來，C 程序員就一直討論此類錯誤，但其影響在 2007 年仍然很大。更糟的是，如果按我的思路考慮，當今的許多 C 和 C++ 程序員可能都會認為內存錯誤是不可控制而又神秘的頑症，它們只能糾正，無法預防。
存在內存錯誤的 C 和 C++ 程序會導致各種問題。如果它們洩漏內存，則運行速度會逐漸變慢，並最終停止運行；如果覆蓋內存，則會變得非常脆弱，很容易受到惡意用戶的攻擊。從 1988 年著名的莫裡斯蠕蟲 攻擊到有關 Flash Player 和其他關鍵的零售級程序的最新安全警報都與緩衝區溢出有關：「大多數計算機安全漏洞都是緩衝區溢出」，Rodney Bates 在 2004 年寫道。
在可以使用 C 或 C++ 的地方，也廣泛支持使用其他許多通用語言（如 Java™、Ruby、Haskell、C#、Perl、Smalltalk 等），每種語言都有眾多的愛好者和各自的優點。但是，從計算角度來看，每種編程語言優於 C 或 C++ 的主要優點都與便於內存管理密切相關。與內存相關的編程是如此重要，而在實踐中正確應用又是如此困難，以致於它支配著面向對像編程語言、功能性編程語言、高級編程語言、聲明性編程語言和另外一些編程語言的所有其他變量或理論。
void f8()
{
struct x *xp;
xp = (struct x *) malloc(sizeof (struct x));
xp.q = 13;
...
free(xp);
...
/* Problem! There's no guarantee that
the memory block to which xp points
hasn't been overwritten. */
return xp.q;
}
/********
* ...
*
* Note that any function invoking protected_file_read()
* assumes responsibility eventually to fclose() its
* return value, UNLESS that value is NULL.
*
********/
FILE *protected_file_read(char *filename)
{
FILE *fp;
fp = fopen(filename, "r");
if (fp) {
...
} else {
...
}
return fp;
}
/*******
* ...
*
* Note that the return value of get_message points to a
* fixed memory location. Do NOT free() it; remember to
* make a copy if it must be retained ...
*
********/
char *get_message()
{
static char this_buffer[400];
...
(void) sprintf(this_buffer, ...);
return this_buffer;
}
/********
* ...
* While this function uses heap memory, and so
* temporarily might expand the over-all memory
* footprint, it properly cleans up after itself.
*
********/
int f6(char *item1)
{
my_class c1;
int result;
...
c1 = new my_class(item1);
...
result = c1.x;
delete c1;
return result;
}
/********
* ...
* Note that f8() is documented to return a value
* which needs to be returned to heap; as f7 thinly
* wraps f8, any code which invokes f7() must be
* careful to free() the return value.
*
********/
int *f7()
{
int *p;
p = f8(...);
...
return p;
}
檢測是編碼標準的補充。二者各有裨益，但結合使用效果特別好。機靈的 C 或 C++ 專業人員甚至可以瀏覽不熟悉的源代碼，並以極低的成本檢測內存問題。通過少量的實踐和適當的文本搜索，您能夠快速驗證平衡的 *alloc() 和 free() 或者 new 和 delete 的源主體。人工查看此類內容通常會出現像清單 7 中一樣的問題。
由於這些原因，我們催促 C 和 C++ 程序員為解決內存問題先瞭解一下自己的源。在這完成之後，才去考慮庫。
使用幾個庫能夠編寫常規的 C 或 C++ 代碼，並保證改進內存管理。Jonathan Bartlett 在 developerWorks 的 2004 評論專欄中介紹了主要的候選項，可以在下面的參考資料部分獲得。庫可以解決多種不同的內存問題，以致於直接對它們進行比較是非常困難的；這方面的常見主題包括垃圾收集、智能指針 和 智能容器。大體上說，庫可以自動進行較多的內存管理，這樣程序員可以犯更少的錯誤。
我對內存庫有各種感受。他們在努力工作，但我看到他們在項目中獲得的成功比預期要小，尤其在 C 方面。我尚未對這些令人失望的結果進行仔細分析。例如，業績應該與相應的手動 內存管理一樣好，但是這是一個灰色區域——尤其在垃圾收集庫處理速度緩慢的情況下。通過這方面的實踐得出的最明確的結論是，與 C 關注的代碼組相比，C++ 似乎可以較好地接受智能指針。
