| #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）。
