寫出那些不會導致任何內存泄漏的代碼。很明顯,當妳的代碼中到處充滿了new 操作、delete操作和指針運算的話,妳將會在某個地方搞暈了頭,導致內存泄漏,指針引用錯誤,以及諸如此類的問題。這和妳如何小心地對待內存分配工作其實完全沒有關系:代碼的復雜性最終總是會超過妳能夠付出的時間和努力。於是隨後產生了壹些成功的技巧,它們依賴於將內存分配(allocations)與重新分配(deallocation)工作隱藏在易於管理的類型之後。標準容器(standard containers)是壹個優秀的例子。它們不是通過妳而是自己為元素管理內存,從而避免了產生糟糕的結果。想象壹下,沒有string和vector的幫助,寫出這個:
#include<vector>
#include<string>
#include<iostream>
#include<algorithm>
using namespace std;
int main() // small program messing around with strings
{
cout << "enter some whitespace-separated words:\n";
vector<string> v;
string s;
while (cin>>s) v.push_back(s);
sort(v.begin(),v.end());
string cat;
typedef vector<string>::const_iterator Iter;
for (Iter p = v.begin(); p!=v.end(); ++p) cat += *p+"+";
cout << cat << '\n';
}
妳有多少機會在第壹次就得到正確的結果?妳又怎麽知道妳沒有導致內存泄漏呢?
註意,沒有出現顯式的內存管理,宏,造型,溢出檢查,顯式的長度限制,以及指針。通過使用函數對象和標準算法(standard algorithm),我可以避免使用指針——例如使用叠代子(iterator),不過對於壹個這麽小的程序來說有點小題大作了。
這些技巧並不完美,要系統化地使用它們也並不總是那麽容易。但是,應用它們產生了驚人的差異,而且通過減少顯式的內存分配與重新分配的次數,妳甚至可以使余下的例子更加容易被跟蹤。早在1981年,我就指出,通過將我必須顯式地跟蹤的對象的數量從幾萬個減少到幾打,為了使程序正確運行而付出的努力從可怕的苦工,變成了應付壹些可管理的對象,甚至更加簡單了。
如果妳的程序還沒有包含將顯式內存管理減少到最小限度的庫,那麽要讓妳程序完成和正確運行的話,最快的途徑也許就是先建立壹個這樣的庫。
模板和標準庫實現了容器、資源句柄以及諸如此類的東西,更早的使用甚至在多年以前。異常的使用使之更加完善。
如果妳實在不能將內存分配/重新分配的操作隱藏到妳需要的對象中時,妳可以使用資源句柄(resource handle),以將內存泄漏的可能性降至最低。這裏有個例子:我需要通過壹個函數,在空閑內存中建立壹個對象並返回它。這時候可能忘記釋放這個對象。畢竟,我們不能說,僅僅關註當這個指針要被釋放的時候,誰將負責去做。使用資源句柄,這裏用了標準庫中的auto_ptr,使需要為之負責的地方變得明確了。
#include<memory>
#include<iostream>
using namespace std;
struct S {
S() { cout << "make an S\n"; }
~S() { cout << "destroy an S\n"; }
S(const S&) { cout << "copy initialize an S\n"; }
S& operator=(const S&) { cout << "copy assign an S\n"; }
};
S* f()
{
return new S; // 誰該負責釋放這個S?
};
auto_ptr<S> g()
{
return auto_ptr<S>(new S); // 顯式傳遞負責釋放這個S
}
int main()
{
cout << "start main\n";
S* p = f();
cout << "after f() before g()\n";
// S* q = g(); // 將被編譯器捕捉
auto_ptr<S> q = g();
cout << "exit main\n";
// *p產生了內存泄漏
// *q被自動釋放
}
在更壹般的意義上考慮資源,而不僅僅是內存。
如果在妳的環境中不能系統地應用這些技巧(例如,妳必須使用別的地方的代碼,或者妳的程序的另壹部分簡直是原始人類(譯註:原文是Neanderthals,尼安德特人,舊石器時代廣泛分布在歐洲的猿人)寫的,如此等等),那麽註意使用壹個內存泄漏檢測器作為開發過程的壹部分,或者插入壹個垃圾收集器(garbage collector)。