C/C++语言中有许多对初学者(甚至是有经验的编程人员)来说很容易范的错误。通晓这样的错误可使你免于陷入其中。
忘记初始化指针
这种错误只是一般"忘记初始化变量"错误的一个特殊形式(C/C++中变量不会自动初始化，而Basic可以)。使这种错误更糟糕的原因是它的后果往往更加糟糕：
void SomeFunction()
{
int *pnVar
int nVal;
nVal = *pnVar; // Bad enough.
*pnVar = nVal; // Much worse.
}
在这个例子中，指针变量pnVar从未被赋值。因此你必须假设它含有的是杂乱的数据，从一个混乱信息指针中读数糟糕的很，因为结果肯定是杂乱数据，向一个混乱信息指针写数据更糟，因为它将导致一些不知道什么地方的数据被重写。
如果被重写的区域无用，这到没什么危害。如果被重写的区域有用，数据就会丢失。这种类型的错误那么难找，是因为直到程序企图使用已丢失的数据时问题才会呈现出来。这种问题可能是在数据丢失后好久才发生的。
由于这一问题手工判断很困难，Visual C++编译器就通过一些努力来避免它的发生。例如，当你编译上述函数时就会产生一个警告。在这种情况下，编译器会告诉你变量在使用前未被赋值。在很多情况下，它不可能告诉你。
Windows 95操作系统试图用保护存储器在一定程度上帮助解决难题：如果应用程序企图从不属于它的存储器读或写，Windows通常能截获该请求，并立即终止该程序。可惜，Windows 95不能截获对应用程序拥有的存储器的无效访问，它也不能截获所有非法访问，因为必须保留某些缺口，以与Windows 3.1的兼容性名义开放。
忘记释放堆内存
请记住从堆获得分配的任何内存都必须要释放。如果你用完内存以后，忘记释放它，系统内存就会变得愈来愈小，直到最后你的程序不能运行而崩溃。
这个问题会出现在诸如下列的一些情况中：
Car* GetAnewCar(int nOccupants)
{
Car* pCar;
if(nOccupants < 4)
{
pCar = new Car(2); // get a two-door.
}
else
{
pCar = new Car(4); // otherwise, a four-door.
}
return pCar;
}
void GoToTheStore(int nOccupants)
{
// get a car。
Car* pCar = GetAnewCar(nOccupants);
// Now drive to the store。
if(pCar)
{
pCar->Drive(Store);
}
}
在此例中，函数GoToTheStore()首先分配一辆新车来开——这有点浪费，但你肯定会同意这种算法可以正常工作。只要分配了新车，它就会开到有调用pCar->Drive(Store)所指向的商店。
问题是在它安全到达目的地之后，函数不破坏Car对象。它只是简单地退出，从而使内存丢失。
通常，当对象pCar出了程序中的作用域时，程序员应该依靠析构函数~Car释放内存。但这里办不到，因为pCar的类型不是Car而是Car*,当pCar出了作用域时不会调用析构函数。
修正的函数如下：
void GoToTheStore(int nOccupants)
{
// get a car。
Car* pCar = GetAnewCar(nOccupants);
// Now drive to the store。
if(pCar)
{
pCar->Drive(Store);
}
// Now delete the object,returning the memory.
delete pCar;
}
使用new操作符构造的对象都应该用delete运算符删除，这一点必须牢记。
返回对局部内存的引用
另一个常见的与内存有关的问题是从函数返回局部内存对象的地址。当函数返回时，对象不再有效。下一次调用某函数时，这个内存地址可能会被这个新函数使用。继续使用这个内存指针就有可能会写入新函数的局部内存。
这个常见问题以这种方式出现：
Car* GetAnewCar(int nOccupants)
{
Car* pCar;
if(nOccupants < 4)
{
pCar = &Car(2); // get a two-door.
}
else
{
pCar = &Car(4); // otherwise, a four-door.
}
return pCar;
}
请注意指针pCar怎样被赋予由构造函数Car()建立的未命名对象的局部地址的。到目前为止，没有问题。然而一旦函数返回这个地址，问题就产生了，因为在封闭的大括号处临时对象会被析构。
使运算符混乱
C++从它的前辈C那里继承了一套含义相当混乱模糊的运算符。再加上语法规则的灵活性，就使它很容易对程序员造成混乱，使程序员去使用错误的运算符。
这个情况的最出名的例子如下：
if(nVal = 0)
{
// do something if nVal is nonzero.
}
程序员显然想要写if(nVal == 0)。不幸的是，上述语句是完全合法的，虽然没有什么意义，C++语句将nVal赋值为0，然后检查结果看看是否为非零（这是不可能发生的）。结果是大括号内的代码永远不会被执行。
其它几对容易弄错的运算符是&和&&，以及/和//。
0的四种面孔
根据使用它的方式，常数0有四种可能的含义：
整数0
不能是对象地址的地址
逻辑FALSE
字符串的终结符
我可以向你证明这些含义的差别是很实际的。例如，下列赋值是合法的：
int *pInt;
pInt = 0;// this is leagal.
而下列赋值是不合法的：
int *pInt;
pInt = 1;// this is not.
第一个赋值是合法的，因为表中的第二定义：常数0可以是地址，然而常数1则不行。
这个含义的多重性能导致一些难以发现的错误：
// copy a string from pSource to pTarget -- incorrect version.
while(pSource)
{
*pTarget++ = *pSource++;
}
此例中的while循环试图把由pSource指向的源字符串复制到由pTarget指向的内存块。但不幸的是，条件写错了，它应这样写出：
// copy a string from pSource to pTarget -- incorrect version.
while(*pSource)
{
*pTarget++ = *pSource++;
}
你可以看到，当由pSource指向的字符为NULL时，终止条件出现。这是0的第四定义。然而，这里写出的代码却是去查看地址pSource是否为零，这是第二定义。
最终结果是while()循环继续写入内存直到程序崩溃。
0的其他定义之间也可能产生混乱。唯一的解决办法就是当你使用常数0的时候小心一点。
声明的混乱处
复合声明是非常混乱的，但C++——以它的热忱保持了与C的反向兼容性——但也产生了一些声明间的矛盾，你必须避免这种矛盾。
class Myclass
{
public:
Myclass(int nArg1 = 0,int nArg2 = 0);
};
Myclass mcA(1,2);
Myclass mcB(1);
Myclass mcC();
mcA是参数1和2构成的对象，而mcB是参数1和0构成的对象。因此你可能认为mcC是参数0和0构成的对象，然而情况不是这样。而mcC()是一个不带参数的函数，它用数值返回类Myclass的对象。
另一个混乱产生于初始化运算符=的使用：
Myclass mcB = nA; // same as Myclass mcB(nA)
为了增强与C的兼容性，允许这样使用=；然而你应该避免这种结构，因为它不是一贯适用的。例如下列程序就不会有预期的效果：
Myclass mcA = nA,nB;
这说明一个对象mcA(nA),它后面有一个独立的使用缺省构造符的对象nB，而不是说明一个对象mcA(nA,nB)。
坚持使用C++格式——这是最安全的。
计算顺序混乱
C和C++运算符的先后顺序，使你能够知道怎样计算诸如下列表达式：
a = b * c + d;
然而先后次序不会影响子表达式的计算顺序。让我们以看上去不重要的方式改变示例的表达式：
a = b() * c() + d();
现在的问题是，在这个表达式中以什么样的顺序调用函数b()，c()和d()？答案是，顺序是完全不确定的。更糟的是，顺序不能借助圆括号的使用而确定。所以下列表达式没有作用：
a = (b() * c()) + d();
函数计算顺序通常不值得去关心。然而，如果这些函数有副作用，以某种方式彼此影响(称为相互副作用)，那么顺序就是重要的了。例如，如果这些函数改变相同的全局变量，则结果就是不同的，这取决于其中函数被调用的顺序。
甚至当不涉及函数调用时，相互副作用也会产生影响：
int nI = 0;
cout<<"nA[0]="<这个表达式的问题是单个表达式包含有相互副作用的两个子表达式——变量nI是增量。哪个nA[nI++]首先被执行，左边的nA[nI++]还是右边的nA[nI++]?没法说，上述代码可能会以预期的方式工作，但也可能不会。
说明虚拟成员函数
为了在子类中重载虚拟成员函数，必须用和基本类中函数一样的形式说明子类中函数的参数和返回类型。这并不总是清楚的。例如，下列代码似乎讲得通：
class Base
{
public:
virtual void AFunc(Base *pB);
};
class Subclass:public Base
{
public:
virtual void AFunc(Subclass *pS);
};
这个代码会编译通过，但不会有迟后联编。函数Base::AFunc()的参数是Base*类型的，而函数Subclass::AFunc()的参数是Subclass*，它们是不同的。
这个规则的唯一例外是下面的例子，它符合ANSI C++标准：
class Base
{
public:
virtual void Base* AFunc();
};
class Subclass:public Base
{
public:
virtual void Subclass* AFunc();
};
在此例中，每个函数返回其固有类型对象的地址。这种技术很通用，所以标准委员会决定承认它。
从构造函数内调用虚拟成员函数
从构造符内调用虚拟函数是前期联编的，这样，它就短路掉了那些原本可能的简洁的能力：
class Base
{
public:
Base();
virtual void BuildSection();
};
class Subclass:public Base
{
public:
Subclass();
virtual void BuildSection();
};
Base::Base()
{
BuildSection();
};
在此例中，程序员希望构造函数能够多态地调用BuildSection()，当正在构造的对象是Base对象时调用Base::BuildSection()，当对象是类Subclass对象时调用Subclass::BuildSection()。
由于下列简单的原因这个例子不起作用：当调用BuildSection()完成时，正在构造的对象仅仅是一个Base对象。即使对象最终成为Subclass对象，也要等到Subclass的构造函数把它过一遍以后。在这些情况下调用Subclass::BuildSection()可能是致命的。即使对象将最终成为Subclass对象，但在调用BuildSection()的时候，对象只不过是Base对象，而且，这个调用必须要前期联编到函数Base::BuildSection()。
指针对准
当你在80x86处理器（例如，你的PC机的芯片）上执行你的程序时，这个问题不是致命的，但对其他的绝大多数芯片来说，这就是致命的了。它还会对你的应用程序移植到某个其他环境的能力产生影响。此外，甚至对于Intel 处理器来说，这个问题也将导致低于标准的性能。
当你的指针从一种类型转换到另一种类型的时候，就有可能产生一个非对准指针(misaligned pointer)。处理器一般要求内存块的地址要与一个和这个内存块的尺寸匹配的边界对齐。例如，字只能在字边界上被访问(地址是二的倍数)，双字只能在双字边界上被访问(地址是四的倍数)，依次类推。
编译器通常确保监视这个规则。但是当你的指针类型从一种类型转换成较大类型时，你就可以很容易地违反这个规则：
char cA;
char* pC = &cA;
int* pI;
pI = (int*)pC;
*pI = 0; // this may be fatal.
因为字符仅仅是一个字节长，所以地址&cA可能有任意值，包括奇数值。可是，pI应只包含四的倍数的地址。通过转换，允许把pC赋给pI，但是如果地址不是四的倍数，则接着发生的赋值可能使程序崩溃。
对于Intel处理器来说，甚至当pC值为奇数时，该赋值也不是致命的；虽然占用的时间要长得多，但是赋值还是能够正常执行。请你谨防非对准指针。
忘记初始化指针
这种错误只是一般"忘记初始化变量"错误的一个特殊形式(C/C++中变量不会自动初始化，而Basic可以)。使这种错误更糟糕的原因是它的后果往往更加糟糕：
void SomeFunction()
{
int *pnVar
int nVal;
nVal = *pnVar; // Bad enough.
*pnVar = nVal; // Much worse.
}
在这个例子中，指针变量pnVar从未被赋值。因此你必须假设它含有的是杂乱的数据，从一个混乱信息指针中读数糟糕的很，因为结果肯定是杂乱数据，向一个混乱信息指针写数据更糟，因为它将导致一些不知道什么地方的数据被重写。
如果被重写的区域无用，这到没什么危害。如果被重写的区域有用，数据就会丢失。这种类型的错误那么难找，是因为直到程序企图使用已丢失的数据时问题才会呈现出来。这种问题可能是在数据丢失后好久才发生的。
由于这一问题手工判断很困难，Visual C++编译器就通过一些努力来避免它的发生。例如，当你编译上述函数时就会产生一个警告。在这种情况下，编译器会告诉你变量在使用前未被赋值。在很多情况下，它不可能告诉你。
Windows 95操作系统试图用保护存储器在一定程度上帮助解决难题：如果应用程序企图从不属于它的存储器读或写，Windows通常能截获该请求，并立即终止该程序。可惜，Windows 95不能截获对应用程序拥有的存储器的无效访问，它也不能截获所有非法访问，因为必须保留某些缺口，以与Windows 3.1的兼容性名义开放。
忘记释放堆内存
请记住从堆获得分配的任何内存都必须要释放。如果你用完内存以后，忘记释放它，系统内存就会变得愈来愈小，直到最后你的程序不能运行而崩溃。
这个问题会出现在诸如下列的一些情况中：
Car* GetAnewCar(int nOccupants)
{
Car* pCar;
if(nOccupants < 4)
{
pCar = new Car(2); // get a two-door.
}
else
{
pCar = new Car(4); // otherwise, a four-door.
}
return pCar;
}
void GoToTheStore(int nOccupants)
{
// get a car。
Car* pCar = GetAnewCar(nOccupants);
// Now drive to the store。
if(pCar)
{
pCar->Drive(Store);
}
}
在此例中，函数GoToTheStore()首先分配一辆新车来开——这有点浪费，但你肯定会同意这种算法可以正常工作。只要分配了新车，它就会开到有调用pCar->Drive(Store)所指向的商店。
问题是在它安全到达目的地之后，函数不破坏Car对象。它只是简单地退出，从而使内存丢失。
通常，当对象pCar出了程序中的作用域时，程序员应该依靠析构函数~Car释放内存。但这里办不到，因为pCar的类型不是Car而是Car*,当pCar出了作用域时不会调用析构函数。
修正的函数如下：
void GoToTheStore(int nOccupants)
{
// get a car。
Car* pCar = GetAnewCar(nOccupants);
// Now drive to the store。
if(pCar)
{
pCar->Drive(Store);
}
// Now delete the object,returning the memory.
delete pCar;
}
使用new操作符构造的对象都应该用delete运算符删除，这一点必须牢记。
返回对局部内存的引用
另一个常见的与内存有关的问题是从函数返回局部内存对象的地址。当函数返回时，对象不再有效。下一次调用某函数时，这个内存地址可能会被这个新函数使用。继续使用这个内存指针就有可能会写入新函数的局部内存。
这个常见问题以这种方式出现：
Car* GetAnewCar(int nOccupants)
{
Car* pCar;
if(nOccupants < 4)
{
pCar = &Car(2); // get a two-door.
}
else
{
pCar = &Car(4); // otherwise, a four-door.
}
return pCar;
}
请注意指针pCar怎样被赋予由构造函数Car()建立的未命名对象的局部地址的。到目前为止，没有问题。然而一旦函数返回这个地址，问题就产生了，因为在封闭的大括号处临时对象会被析构。
使运算符混乱
C++从它的前辈C那里继承了一套含义相当混乱模糊的运算符。再加上语法规则的灵活性，就使它很容易对程序员造成混乱，使程序员去使用错误的运算符。
这个情况的最出名的例子如下：
if(nVal = 0)
{
// do something if nVal is nonzero.
}
程序员显然想要写if(nVal == 0)。不幸的是，上述语句是完全合法的，虽然没有什么意义，C++语句将nVal赋值为0，然后检查结果看看是否为非零（这是不可能发生的）。结果是大括号内的代码永远不会被执行。
其它几对容易弄错的运算符是&和&&，以及/和//。
0的四种面孔
根据使用它的方式，常数0有四种可能的含义：
整数0
不能是对象地址的地址
逻辑FALSE
字符串的终结符
我可以向你证明这些含义的差别是很实际的。例如，下列赋值是合法的：
int *pInt;
pInt = 0;// this is leagal.
而下列赋值是不合法的：
int *pInt;
pInt = 1;// this is not.
第一个赋值是合法的，因为表中的第二定义：常数0可以是地址，然而常数1则不行。
这个含义的多重性能导致一些难以发现的错误：
// copy a string from pSource to pTarget -- incorrect version.
while(pSource)
{
*pTarget++ = *pSource++;
}
此例中的while循环试图把由pSource指向的源字符串复制到由pTarget指向的内存块。但不幸的是，条件写错了，它应这样写出：
// copy a string from pSource to pTarget -- incorrect version.
while(*pSource)
{
*pTarget++ = *pSource++;
}
你可以看到，当由pSource指向的字符为NULL时，终止条件出现。这是0的第四定义。然而，这里写出的代码却是去查看地址pSource是否为零，这是第二定义。
最终结果是while()循环继续写入内存直到程序崩溃。
0的其他定义之间也可能产生混乱。唯一的解决办法就是当你使用常数0的时候小心一点。
声明的混乱处
复合声明是非常混乱的，但C++——以它的热忱保持了与C的反向兼容性——但也产生了一些声明间的矛盾，你必须避免这种矛盾。
class Myclass
{
public:
Myclass(int nArg1 = 0,int nArg2 = 0);
};
Myclass mcA(1,2);
Myclass mcB(1);
Myclass mcC();
mcA是参数1和2构成的对象，而mcB是参数1和0构成的对象。因此你可能认为mcC是参数0和0构成的对象，然而情况不是这样。而mcC()是一个不带参数的函数，它用数值返回类Myclass的对象。
另一个混乱产生于初始化运算符=的使用：
Myclass mcB = nA; // same as Myclass mcB(nA)
为了增强与C的兼容性，允许这样使用=；然而你应该避免这种结构，因为它不是一贯适用的。例如下列程序就不会有预期的效果：
Myclass mcA = nA,nB;
这说明一个对象mcA(nA),它后面有一个独立的使用缺省构造符的对象nB，而不是说明一个对象mcA(nA,nB)。
坚持使用C++格式——这是最安全的。
计算顺序混乱
C和C++运算符的先后顺序，使你能够知道怎样计算诸如下列表达式：
a = b * c + d;
然而先后次序不会影响子表达式的计算顺序。让我们以看上去不重要的方式改变示例的表达式：
a = b() * c() + d();
现在的问题是，在这个表达式中以什么样的顺序调用函数b()，c()和d()？答案是，顺序是完全不确定的。更糟的是，顺序不能借助圆括号的使用而确定。所以下列表达式没有作用：
a = (b() * c()) + d();
函数计算顺序通常不值得去关心。然而，如果这些函数有副作用，以某种方式彼此影响(称为相互副作用)，那么顺序就是重要的了。例如，如果这些函数改变相同的全局变量，则结果就是不同的，这取决于其中函数被调用的顺序。
甚至当不涉及函数调用时，相互副作用也会产生影响：
int nI = 0;
cout<<"nA[0]="<这个表达式的问题是单个表达式包含有相互副作用的两个子表达式——变量nI是增量。哪个nA[nI++]首先被执行，左边的nA[nI++]还是右边的nA[nI++]?没法说，上述代码可能会以预期的方式工作，但也可能不会。
说明虚拟成员函数
为了在子类中重载虚拟成员函数，必须用和基本类中函数一样的形式说明子类中函数的参数和返回类型。这并不总是清楚的。例如，下列代码似乎讲得通：
class Base
{
public:
virtual void AFunc(Base *pB);
};
class Subclass:public Base
{
public:
virtual void AFunc(Subclass *pS);
};
这个代码会编译通过，但不会有迟后联编。函数Base::AFunc()的参数是Base*类型的，而函数Subclass::AFunc()的参数是Subclass*，它们是不同的。
这个规则的唯一例外是下面的例子，它符合ANSI C++标准：
class Base
{
public:
virtual void Base* AFunc();
};
class Subclass:public Base
{
public:
virtual void Subclass* AFunc();
};
在此例中，每个函数返回其固有类型对象的地址。这种技术很通用，所以标准委员会决定承认它。
从构造函数内调用虚拟成员函数
从构造符内调用虚拟函数是前期联编的，这样，它就短路掉了那些原本可能的简洁的能力：
class Base
{
public:
Base();
virtual void BuildSection();
};
class Subclass:public Base
{
public:
Subclass();
virtual void BuildSection();
};
Base::Base()
{
BuildSection();
};
在此例中，程序员希望构造函数能够多态地调用BuildSection()，当正在构造的对象是Base对象时调用Base::BuildSection()，当对象是类Subclass对象时调用Subclass::BuildSection()。
由于下列简单的原因这个例子不起作用：当调用BuildSection()完成时，正在构造的对象仅仅是一个Base对象。即使对象最终成为Subclass对象，也要等到Subclass的构造函数把它过一遍以后。在这些情况下调用Subclass::BuildSection()可能是致命的。即使对象将最终成为Subclass对象，但在调用BuildSection()的时候，对象只不过是Base对象，而且，这个调用必须要前期联编到函数Base::BuildSection()。
指针对准
当你在80x86处理器（例如，你的PC机的芯片）上执行你的程序时，这个问题不是致命的，但对其他的绝大多数芯片来说，这就是致命的了。它还会对你的应用程序移植到某个其他环境的能力产生影响。此外，甚至对于Intel 处理器来说，这个问题也将导致低于标准的性能。
当你的指针从一种类型转换到另一种类型的时候，就有可能产生一个非对准指针(misaligned pointer)。处理器一般要求内存块的地址要与一个和这个内存块的尺寸匹配的边界对齐。例如，字只能在字边界上被访问(地址是二的倍数)，双字只能在双字边界上被访问(地址是四的倍数)，依次类推。
编译器通常确保监视这个规则。但是当你的指针类型从一种类型转换成较大类型时，你就可以很容易地违反这个规则：
char cA;
char* pC = &cA;
int* pI;
pI = (int*)pC;
*pI = 0; // this may be fatal.
因为字符仅仅是一个字节长，所以地址&cA可能有任意值，包括奇数值。可是，pI应只包含四的倍数的地址。通过转换，允许把pC赋给pI，但是如果地址不是四的倍数，则接着发生的赋值可能使程序崩溃。
对于Intel处理器来说，甚至当pC值为奇数时，该赋值也不是致命的；虽然占用的时间要长得多，但是赋值还是能够正常执行。请你谨防非对准指针。
这种情况只在你正在把你的指针从指向一种类型转换成指向较大类型时才会出现
本文转自茄子_2008博客园博客，原文链接：http://www.cnblogs.com/xd502djj/archive/2010/09/23/1833362.html，如需转载请自行联系原作者。
