程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 編程語言 >> C語言 >> C++ >> C++入門知識 >> C++常見錯誤大全(轉),常見錯誤大全

C++常見錯誤大全(轉),常見錯誤大全

編輯:C++入門知識

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)" (?GameShutdown@@YAXXZ)

原因:頭文件(如main.h)聲明了方法GameShutdown(),但main.cpp裡沒有實現它。

排錯:在工程中搜“GameShutdown”,定位在哪個.h文件,再在對應的.cpp文件中添加實現方法。

(2)子類未實現父類純虛函數錯誤:

D3DRenderer.obj : error LNK2001: unresolved external symbol "public: virtual void __thiscall CD3DRenderer::SetMultiTexture(void)" (?SetMultiTexture@CD3DRenderer@@UAEXXZ)
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 *)" (__imp_??0OgreCEGUIRenderer@CEGUI@@QAE@PAVRenderWindow@Ogre@@E_NIPAVSceneManager@3@@Z),該符號在函數 "protected: virtual void __thiscall MouseQueryApplication::createScene(void)" (?createScene@MouseQueryApplication@@MAEXXZ) 中被引用 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中定義的怪現象。

結論:
頭文件中只能聲明結構,萬萬不可以定義變量!!!!

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved