内存管理
C++中涉及到的内存的管理问题可以归结为两方面：正确地得到它和有效地使用它。好的程序员会理解这两个问题为什么要以这样的顺序列出。因为执行得再快、体积再小的程序如果它不按你所想象地那样去执行，那也一点用处都没有。“正确地得到”的意思是正确地调用内存分配和释放程序；而“有效地使用”是指写特定版本的内存分配和释放程序。这里，“正确地得到”显得更重要一些。
然而说到正确性，C++其实从C继承了一个很严重的头疼病，那就是内存泄露隐患。虚拟内存是个很好的发明，但虚拟内存也是有限的，并不是每个人都可以最先抢到它。
在C中，只要用malloc分配的内存没有用free返回，就会产生内存泄露。在C++中，肇事者的名字换成了new和delete，但情况基本上是一样的。当然，因为有了析构函数的出现，情况稍有改善，因为析构函数为所有将被摧毁的对象提供了一个方便的调用delete的场所。但这同时又带来了更多的烦恼，因为new和delete是隐式地调用构造函数和析构函数的。而且，因为可以在类内和类外自定义new和delete操作符，这又带来了复杂性，增加了出错的机会。下面的条款(还有条款M8)将告诉你如何避免产生那些普遍发生的问题。
条款5：对应的new和delete要采用相同的形式
下面的语句有什么错？
string *stringArray = new string[100];
...
delete stringArray;
一切好象都井然有序——一个new对应着一个delete——然而却隐藏着很大的错误：程序的运行情况将是不可预测的。至少，stringArray指向的100个string对象中的99个不会被正确地摧毁，因为他们的析构函数永远不会被调用。
用new的时候会发生两件事。首先，内存被分配(通过operator new 函数，详见条款7-10和条款M8)，然后，为被分配的内存调用一个或多个构造函数。用delete的时候，也有两件事发生：首先，为将被释放的内存调用一个或多个析构函数，然后，释放内存(通过operator delete 函数，详见条款8和M8)。对于 delete来说会有这样一个重要的问题：内存中有多少个对象要被删除？答案决定了将有多少个析构函数会被调用。
这个问题简单来说就是：要被删除的指针指向的是单个对象呢，还是对象数组？这只有你来告诉delete。如果你在用delete时没用括号，delete就会认为指向的是单个对象，否则，它就会认为指向的是一个数组：
string *stringPtr1 = new string;
string *stringPtr2 = new string[100];
...
delete stringPtr1; // 删除一个对象
delete [] stringPtr2; // 删除对象数组
如果你在stringPtr1前加了"[]"会怎样呢？答案是：那将是不可预测的；如果你没在stringPtr2前没加上"[]"又会怎样呢？答案也是：不可预测。而且对于象int这样的固定类型来说，结果也是不可预测的，即使这样的类型没有析构函数。所以，解决这类问题的规则很简单：如果你调用new时用了[]，调用delete时也要用[]。如果调用new时没有用[]，那调用delete时也不要用[]。
在写一个包含指针数据成员，并且提供多个构造函数的类时，牢记这一规则尤其重要。因为这样的话，你就必须在所有初始化指针成员的构造函数里采用相同的new的形式。否则，析构函数里将采用什么形式的delete呢？关于这一话题的进一步阐述，参见条款11。
这个规则对喜欢用typedef的人来说也很重要，因为写typedef的程序员必须告诉别人，用new创建了一个typedef定义的类型的对象后，该用什么形式的delete来删除。举例如下：
typedef string AddressLines[4]; // 一个人的地址，共4行，每行一个string
因为AddressLines是个数组，使用new:
string *pal = new AddressLines; // 注意"new AddressLines"返回string*, 和
// "new string[4]"返回的一样
delete时必须以数组形式与之对应：
delete pal; // 错误!
delete [] pal; // 正确
为了避免混乱，最好杜绝对数组类型用typedefs。这其实很容易，因为标准C++库(见条款49)包含有stirng和vector模板，使用他们将会使对数组的需求减少到几乎零。举例来说，AddressLines可以定义为一个字符串(string)的向量(vector)，即AddressLines可定义为vector<string>类型。
