原文轉自：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事先聲明+指針的形式來解決