malloc和free(及其变体)会产生问题的原因在于它们太简单：他们不知道构造函数和析构函数。

假设用两种方法给一个包含10个string对象的数组分配空间，一个用malloc，另一个用new：

string *stringarray1 =
static_cast<string*>(malloc(10 * sizeof(string)));

string *stringarray2 = new string[10];

其结果是，stringarray1确实指向的是可以容纳10个string对象的足够空间，但内存里并没有创建这些对象。而且，如果你不从这种晦涩的语法怪圈(详见条款m4和m8的描述)里跳出来的话，你没有办法来初始化数组里的对象。换句话说，stringarray1其实一点用也没有。相反，stringarray2指向的是一个包含10个完全构造好的string对象的数组,每个对象可以在任何读取string的操作里安全使用。

假设你想了个怪招对stringarray1数组里的对象进行了初始化，那么在你后面的程序里你一定会这么做：

free(stringarray1);
delete [] stringarray2;// 参见条款5：这里为什么要加上个"[]"

调用free将会释放stringarray1指向的内存，但内存里的string对象不会调用析构函数。如果string对象象一般情况那样，自己已经分配了内存，那这些内存将会全部丢失。相反，当对stringarray2调用delete时，数组里的每个对象都会在内存释放前调用析构函数。

既然new和delete可以这么有效地与构造函数和析构函数交互，选用它们是显然的。

把new和delete与malloc和free混在一起用也是个坏想法。对一个用new获取来的指针调用free，或者对一个用malloc获取来的指针调用delete，其后果是不可预测的。大家都知道“不可预测”的意思：它可能在开发阶段工作良好，在测试阶段工作良好，但也可能会最后在你最重要的客户的脸上爆炸。

new/delete和malloc/free的不兼容性常常会导致一些严重的复杂性问题。举个例子，<string.h>里通常有个strdup函数，它得到一个char*字符串然后返回其拷贝：

char * strdup(const char *ps); // 返回ps所指的拷贝
在有些地方，c和c++用的是同一个strdup版本，所以函数内部是用malloc分配内存。这样的话，一些不知情的c++程序员会在调用strdup后忽视了必须对strdup返回的指针进行free操作。为了防止这一情况，有些地方会专门为c++重写strdup，并在函数内部调用了new，这就要求其调用者记得最后用delete。你可以想象，这会导致多么严重的移植性问题，因为代码中strdup以不同的形式在不同的地方之间颠来倒去。

c++程序员和c程序员一样对代码重用十分感兴趣。大家都知道，有大量基于malloc和free写成的代码构成的c库都非常值得重用。在利用这些库时，最好是你不用负责去free掉由库自己malloc的内存，并且/或者，你不用去malloc库自己会free掉的内存，这样就太好了。其实，在c++程序里使用malloc和free没有错，只要保证用malloc得到的指针用free，或者用new得到的指针最后用delete来操作就可以了。千万别马虎地把new和free或malloc和delete混起来用，那只会自找麻烦。

既然malloc和free对构造函数和析构函数一无所知，把malloc/free和new/delete混起来用又象嘈杂拥挤的晚会那样难以控制，那么，你最好就什么时候都一心一意地使用new和delete吧

旧的c注释语法在c++里还可以用，c++新发明的行尾注释语法也有其过人之处。例如下面这种情形：

if ( a > b ) {
 // int temp = a; // swap a and b
 // a = b;
 // b = temp;
}

假设你出于某种原因要注释掉这个代码块。从软件工程的角度看，写这段代码的程序员也做得很好，他最初的代码里也写了一个注释，以解释代码在做什么。用c++形式的句法来注释掉这个程序块时，嵌在里面的最初的注释不受影响，但如果选择c风格的注释就会发生严重的错误：

if ( a > b ) {
 /* int temp = a;  /* swap a and b */
  a = b;
  b = temp;
 */
}

请注意嵌在代码块里的注释是怎么无意间使本来想注释掉整个代码块的注释提前结束的。

c风格的注释当然还有它存在的价值。例如，它们在c和c++编译器都要处理的头文件中是无法替代的。尽管如此，只要有可能，你最好尽量用c++风格的注释。

值得指出的是，有些老的专门为c写的预处理程序不知道处理c++风格的注释，所以象下面这种情形时，事情就不会象预想的那样：

#define light_speedp 3e8 // m/sec (in a vacuum)

对于不熟悉c++的预处理程序来说，行尾的注释竟然成为了宏的一部分！当然，正象条款1所说的那样，你无论如何也不会用预处理来定义常量的。