【转】C++常见错误大全

原文转自：http://hi.baidu.com/qiou2719/item/b9eed949130ff50ec0161331

C++常见错误大全

0. XXXX "is not a class or namespace"错误
    最诡异的错误，提示意思很明显，说你写的名字既不是一个类也不是一个命名空间，虽然我C＋＋水平不是很高，但再愚笨也不至于连类的格式class MyClass{....};也写不明白吧，报此错误原因显然跟它没关系，那又是怎么回事呢？
    答案是：#include   "stdafx.h"没放在代码最开头！！！
     stdafx.h知识简单说一下：
     所谓头文件预编译，就是把一个工程(Project)中使用的一些MFC 标准头文件(如Windows.H、Afxwin.H)预先编译，以后该工程编译时，不再编译这部分头文件，仅仅使用预编译的结果。这样可以加快编译速度，节省时间。
    预编译头文件通过编译stdafx.cpp 生成，以工程名命名，由于预编译的头文件的后缀是“pch”，所以编译结果文件是projectname.pch。
    没把：#include   "stdafx.h"放在代码最开头会发生什么问题呢？编译器认为，所有在指令#include "stdafx.h"前的代码都是预编译的，它会跳过#include"stdafx. h"之前的指令，使用projectname.pch 编译这条指令之后的所有代码。因此，当然会出现找不到类的错误了。
因此，所有的CPP 实现文件第一条语句都应该是：#include "stdafx.h"。

一.LINK2001错误：

此类错误VS给出提示但双击不会定位到出错地点，提示也莫名其妙，要究其原因排错

(1)error LNK2001: unresolved external symbol "void __cdecl GameShutdown(void)" ()

原因：头文件(如main.h)声明了方法GameShutdown()，但main.cpp里没有实现它。

排错：在工程中搜“GameShutdown”，定位在哪个.h文件，再在对应的.cpp文件中添加实现方法。

(2)子类未实现父类纯虚函数错误：

D3DRenderer.obj : error LNK2001: unresolved external symbol "public: virtual void __thiscall CD3DRenderer::SetMultiTexture(void)" ()
Debug/GameProject4.exe : fatal error LNK1120: 1 unresolved externals

原因：同上，在D3DRenderer.cpp(D3DRenderer.obj对应相应的.cpp)中未实现虚方法SetMultiTexture（）,这个虚方法是在类的CD3DRenderer的父类中声明，虚方法一定要实现，否则会出现unresolved externals错误

排错：简单，在类CD3DRenderer（D3DRenderer.cpp）中实现这个虚方法既可。

//C++ 子类没有实现父类的纯虚函数，则子类也变成抽象类，子类也不能实例化对象
/*在设计基类的时候不好确定将来的行为具体应该表现什么行为，但是必须的。
含有纯虚函数的类叫抽象类。抽象类不能实例化它的对象，只能为它的派生类服务。
如果子类没有实现父类的纯虚函数，则子类也变成抽象类，它也不能实例化对象。
*/

二、LINK2019 无法解析外部符号"__declspec(dllimport)“的错误

错误 1 error LNK2019: 无法解析的外部符号 "__declspec(dllimport) public: __thiscall CEGUI::OgreCEGUIRenderer::OgreCEGUIRenderer(class Ogre::RenderWindow *,unsigned char,bool,unsigned int,class Ogre::SceneManager *)" ()，该符号在函数 "protected: virtual void __thiscall MouseQueryApplication::createScene(void)" () 中被引用 SampleAPP.obj

经典的找不到dll错误，程序调用的方法在dll中定义，解决方法有两步：

1.找到此dll文件，还有对应的同名lib(如果是静态链接库)，根据上述错误为OgreCEGUIRenderer开头的dll文件中，找到后放到你的工作空间(大概是\bin)目录下。

2.如果还是没有解决，那么一定是项目里没有引用相应的lib文件，因为别人的程序代码没有问题但是程序设置里添加了lib文件你可能没有设置，你可以在项目属性-》链接器-》输入-》附加依赖项里添加相应的lib，或者一劳永逸的方法是在程序代码的开头（#include下面）指定：

#pragma comment(lib,"CEGUIBase_d.lib")

这与在项目属性设置是一样的效果，但是会更醒目，第三方用户拷入你的代码不会再出现找不到dll的错误

三、程序中读取磁盘遇到找不到图片，资源文件引起的错误，或调用某个复杂SDK函数失败返回

此类错误vs中不会给出提示，排错很困难，在编程时在可能出错的地方要养成多MessageBox的好习惯

不良写法 if(!m_Device) return; // 如果m_Device创建失败就返回，可是下面的代码不执行，这不是我们想要的

正确写法 if(!m_Device)

{

Messagebox(0, "!m_Device", 0, 0);  return;  //这里可知道程序无故返回是因为m_Device创建失败造成的

}

四、程序中编译通过运行时却出错退出，警告框“某exe 在XXXXXX处出现未处理的异常”

这是最难调的BUG，很多错误只有运行时才暴露，这时需要借助VS中的堆栈监控来查错。

例：运行时弹出 “couldn't add <id, 4002201> twice, Continue?”
         点“否”让程序中断，VS弹出 "Client.exe 在 XXXXXX处出现未处理的异常，是否中断？"点击中断。
  这时打开“调用堆栈”视窗，看到绿色箭头停在哪儿就是哪地方出现的错误，但是一般它停的地方都是WIN API的低层，你是看不出来哪儿有问题，就向堆栈底部找，就是向列表下面找，看是谁调用了出错的方法函数，一步一步找。这时我找到：
  VarContain.Add(XX, XX) 看来是这儿加载时出错，某一关键字段加载了两次，但仍看不出哪儿重复加载，这时再向堆栈底部找。
  SkillProtoData->LoadFromFile(strFilename, .......) 看来是这儿加载文件有问题，用debug监视查看strFileName的文件名和路径，是“skillProtoName.xml”文件，去打开它，果然，文件里“id = 4002201”项有两条，删去一个重复项问题就解决了。

结论：当出现“某exe 在XXXXXX处出现未处理的异常”这样恐怖错误时，堆栈的帮助很重要！！！

四.error LNK2019: 无法解析的外部符号 _WinMain@16，该符号在函数 ___tmainCR...

一，问题描述
MSVCRTD.lib(crtexew.obj) : error LNK2019: 无法解析的外部符号 _WinMain@16，该符号在函数 ___tmainCRTStartup 中被引用 
Debug\jk.exe : fatal error LNK1120: 1 个无法解析的外部命令

error LNK2001: unresolved external symbol _WinMain@16
debug/main.exe:fatal error LNK 1120:1 unresolved externals 
error executing link.exe;

二，原因及解决办法
产生这个问题的真正原因是c语言运行时找不到适当的程序入口函数，

一般情况下，如果是windows程序，那么WinMain是入口函数，在VS2008中新建项目为“win32项目”

如果是dos控制台程序，那么main是入口函数，在VS2008中新建项目为“win32控制台应用程序”

而如果入口函数指定不当，很显然c语言运行时找不到配合函数，它就会报告错误。

修改设置适应你的需求

如果是windows程序：

1.菜单中选择 Project->Properties, 弹出Property Pages窗口

2.在左边栏中依次选择：Configuration Properties->C/C++->Preprocessor,然后在右边栏的Preprocessor Definitions对应的项中删除_CONSOLE, 添加_WINDOWS.

3.在左边栏中依次选择：Configuration Properties->Linker->System,然后在右边栏的SubSystem对应的项改为Windows(/SUBSYSTEM:WINDOWS)

如果是控制台程序：

1.菜单中选择 Project->Properties, 弹出Property Pages窗口

2.在左边栏中依次选择：Configuration Properties->C/C++->Preprocessor,然后在右边栏的Preprocessor Definitions对应的项中删除_WINDOWS, 添加_CONSOLE.

3.在左边栏中依次选择：Configuration Properties->Linker->System,然后在右边栏的SubSystem对应的项改为CONSOLE(/SUBSYSTEM:CONSOLE)

五、**.exe 中的 0x111552a1 处未处理的异常: 0xC0000005: 读取位置 0x00000018 时发生访问冲突

在Ogre::ResourceGroupManager::getSingleton().addResourceLocation( "resource\gui.zip", "Zip", "GUI"); 处程序中断

提示又是像外星文天书一般晦涩，看来排错成功希望渺茫。上网查查看人家说，0xC0000005一般表示空指针，加这里涉及到读取资源可以猜测可能路径不对。果然相对路径"resource\gui.zip" 改成绝对的"d:\\gui.zip",就正常了，但是放在工程目录下还是有问题 ，那这个相对路径是相对哪儿的呢？工作空间难道设置的有问题吗？

查“项目属性”->“调试”->"工作空间" 设置是“..\bin\Debug”， 退回上级目录进入此目录一看，果然没有“resource”文件夹。在此新建一个“resource”文件夹，再放一个“gui.zip”文件放进去，再编译，还是报错，仔细检查，改成“resource\\gui.zip”，结果终于编译成功了!

心得： 所谓工作空间就是相当于传统意义的工程文件夹，所以相对路径都是相对此目录的，而不是你想当然的程序目录。还有程序代码写路径时一定要双划线，切记！

六、error C2360: initialization of 'c' is skipped by 'case' label

void   func(   void   )   
{   
        int   x;   
        switch   (   x   )   
        {   
        case   0   :   
              int   i   =   1;               //   error,   skipped   by   case   1       
              {   int   j   =   1;   }       //   ok,   initialized   in   enclosing   block   
        case   1   :   
              int   k   =   1;               //   ok,   initialization   not   skipped   
        }   
}  
在switch语句内定义一个变量的时候，如果不在一个语句块内，它是直到遇到switch的"}"才结束的。

所以，如果有在case内定义新变量，最好将该条case内的语句加上{}构成语句块，避免出错
要么就不在case内定义变量，要定义整个case加上{}

七、“UINT WM_MY_REGISTERED_MSG” 已经在“XXX.obj”中定义
#pragma once不能解决头文件重复定义变量

咋一看，分明是UINT WM_MY_REGISTERED_MSG变量在XXX.cpp中重复定义了，可是搜遍整个工程，只发现 WM_MY_REGISTERED_MSG只在userMsg.h头文件中定义一处：UINT WM_MY_REGISTERED_MSG; 别处再无定义，这是怎么回事呢？
想起以前有位恩师反复告诉过我，头文件中只适合#define 常量和声明类和结构体的结构，不适合定义变量，要定义变量都要在.cpp中定义。那我试试把UINT WM_MY_REGISTERED_MSG放在主文件userMsg.cpp中，果然没错了。

看来是头文件多处包含惹的祸，虽然头文件已经写了#pragma once能解决头文件重复包含，但不能解决重复定义变量。在一个头文件中定义了一个变量，哪怕是再不起眼的int n;只要这个头文件被多个cpp #include，那这个int n就算是重复定义，就会报XXX 已经在 XXX.obj中定义的怪现象。

结论：
头文件中只能声明结构，万万不可以定义变量！！！！

八、VS2005编译DLL错误 error C2491: "XXXXXX": definition of dllimport function not allowed
dll头件：dll_object.h
#ifdef DLL_OBJECT_EXPORT
#define DLL_OBJECT_API __declspec(dllexport)
#else 
#define DLL_OBJECT_API __declspec(dllimport)
#endif
DLL_OBJECT_API void FuncInDll(void);
extern DLL_OBJECT_API int g_nDll;
class DLL_OBJECT_API CDll_Object
{
public:
 CDll_Object(void);
 void show(void);
};

dll_object.cpp:
#define DLL_OBJECT_EXPORTS
#include <Windows.h>
#include <iostream>
#include "dll_object.h"
using namespace std;

DLL_OBJECT_API void FuncInDll(void)
{
   cout << "This is FuncInDll"<<endl;
}

DLL_OBJECT_API int g_nDll = 9;

CDll_Object::CDll_Object()
{
 cout << "class of CDll_Object" << endl;
}

void CDll_Object::show()
{
 cout<<"function show in class CDll_Object"<<endl;
}
这样写完全没问题，但是老是报error C2491: "XXXXXX": definition of dllimport function not allowed 错，解决方案：
改变VS2005的编译器生成的预定义宏。
我建立的项目名字是MyClass,系统就自定义生成了MyClass_EXPORTS，改成程序中用到的DLL_OBJECT_EXPORTS就能编译通过了

八. A buffer overrun has occured
缓冲区溢出，可能是数组越界，范围太小而存的东西太多升造成

九.

fatal error CVT1100: duplicate resource. type:MANIFEST, name:1, language:0x0409
解决办法：在工程的rc文件中，搜索类似 RT_MANIFEST             "res//TestApp.manifest"，然后删除掉就OK了

十、头文件相互包含导致的错误
例，有一个状态类
#include "Player.h"
class State
{
public:
 virtual void execute(Player* mutou);
};
Player类
#include "State.h"
class Player
{
 public:
   void changeState(State* curState);

}
编译时Player始终报Sate符号错误，说明类Sate有问题，可是看类State就是看不出什么毛病，看了半天才知道，原来State需要用到Player类，而Player又要用到State类，两者相互包含导致一个无解的死循环，所以报错
那怎么办，就真的无解了吗？肯定不是，可以用指针+类声明解决, State类把include "Player.h"去掉，改成这样
class Player;  //要用到的类事先声明
class State ...//下面的和以前一样

然后在State.cpp里再包含 Player.h就可以了，这样就解决了头文件互相包含的问题， Player.h也作相应处理

注意此法只能适应头文件里包含的类是指针形式，如void execute(Player* mutou);，如果参数不是用指针而是实例如 void execute(Player player)就不行了
总体原则上头文件尽量在.cpp里包含，当然避免不了的就采用这种class XX事先声明+指针的形式来解决