• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            隨筆 - 7  文章 - 15  trackbacks - 0
            <2025年8月>
            272829303112
            3456789
            10111213141516
            17181920212223
            24252627282930
            31123456

            常用鏈接

            留言簿(2)

            隨筆檔案(7)

            相冊

            搜索

            •  

            積分與排名

            • 積分 - 15890
            • 排名 - 955

            最新評論

            閱讀排行榜

            評論排行榜

            上網(wǎng)搜東西的時候搜到了這個,覺得蠻使用的,放在這里以備后用!

            --??LINK2001
            學(xué)習(xí)VC++時經(jīng)常會遇到鏈接錯誤LNK2001,該錯誤非常討厭,因為對于
            編程者來說,最好改的錯誤莫過于編譯錯誤,而一般說來發(fā)生連接錯誤時,
            編譯都已通過。產(chǎn)生連接錯誤的原因非常多,尤其LNK2001錯誤,常常使人不
            明其所以然。如果不深入地學(xué)習(xí)和理解VC++,要想改正連接錯誤LNK2001非
            常困難。
              初學(xué)者在學(xué)習(xí)VC++的過程中,遇到的LNK2001錯誤的錯誤消息主要為:
              unresolved external symbol “symbol”(不確定的外部“符號”)。
              如果連接程序不能在所有的庫和目標(biāo)文件內(nèi)找到所引用的函數(shù)、變量或
            標(biāo)簽,將產(chǎn)生此錯誤消息。一般來說,發(fā)生錯誤的原因有兩個:一是所引用
            的函數(shù)、變量不存在、拼寫不正確或者使用錯誤;其次可能使用了不同版本
            的連接庫。
              以下是可能產(chǎn)生LNK2001錯誤的原因:
              一.由于編碼錯誤導(dǎo)致的LNK2001。
              1.不相匹配的程序代碼或模塊定義(.DEF)文件能導(dǎo)致LNK2001。例如,
            如果在C++ 源文件內(nèi)聲明了一變量“var1”,卻試圖在另一文件內(nèi)以變量
            “VAR1”訪問該變量,將發(fā)生該錯誤。
              2.如果使用的內(nèi)聯(lián)函數(shù)是在.CPP文件內(nèi)定義的,而不是在頭文件內(nèi)定
            義將導(dǎo)致LNK2001錯誤。
              3.調(diào)用函數(shù)時如果所用的參數(shù)類型同函數(shù)聲明時的類型不符將會產(chǎn)生
            LNK2001。
              4.試圖從基類的構(gòu)造函數(shù)或析構(gòu)函數(shù)中調(diào)用虛擬函數(shù)時將會導(dǎo)致LNK2001。
              5.要注意函數(shù)和變量的可公用性,只有全局變量、函數(shù)是可公用的。
              靜態(tài)函數(shù)和靜態(tài)變量具有相同的使用范圍限制。當(dāng)試圖從文件外部訪問
            任何沒有在該文件內(nèi)聲明的靜態(tài)變量時將導(dǎo)致編譯錯誤或LNK2001。
              函數(shù)內(nèi)聲明的變量(局部變量) 只能在該函數(shù)的范圍內(nèi)使用。
              C++ 的全局常量只有靜態(tài)連接性能。這不同于C,如果試圖在C++的
            多個文件內(nèi)使用全局變量也會產(chǎn)生LNK2001錯誤。一種解決的方法是需要時在
            頭文件中加入該常量的初始化代碼,并在.CPP文件中包含該頭文件;另一種
            方法是使用時給該變量賦以常數(shù)。
              二.由于編譯和鏈接的設(shè)置而造成的LNK2001
              1.如果編譯時使用的是/NOD(/NODEFAULTLIB)選項,程序所需要的運(yùn)行
            庫和MFC庫在連接時由編譯器寫入目標(biāo)文件模塊, 但除非在文件中明確包含
            這些庫名,否則這些庫不會被鏈接進(jìn)工程文件。在這種情況下使用/NOD將導(dǎo)
            致錯誤LNK2001。
              2.如果沒有為wWinMainCRTStartup設(shè)定程序入口,在使用Unicode和MFC
            時將得到“unresolved external on _WinMain@16”的LNK2001錯誤信息。
              3.使用/MD選項編譯時,既然所有的運(yùn)行庫都被保留在動態(tài)鏈接庫之內(nèi),
            源文件中對“func”的引用,在目標(biāo)文件里即對“__imp__func” 的引用。
            如果試圖使用靜態(tài)庫LIBC.LIB或LIBCMT.LIB進(jìn)行連接,將在__imp__func上發(fā)
            生LNK2001;如果不使用/MD選項編譯,在使用MSVCxx.LIB連接時也會發(fā)生LNK2001。
              4.使用/ML選項編譯時,如用LIBCMT.LIB鏈接會在_errno上發(fā)生LNK2001。
              5.當(dāng)編譯調(diào)試版的應(yīng)用程序時,如果采用發(fā)行版模態(tài)庫進(jìn)行連接也會產(chǎn)
            生LNK2001;同樣,使用調(diào)試版模態(tài)庫連接發(fā)行版應(yīng)用程序時也會產(chǎn)生相同的
            問題。
              6.不同版本的庫和編譯器的混合使用也能產(chǎn)生問題,因為新版的庫里可
            能包含早先的版本沒有的符號和說明。
              7.在不同的模塊使用內(nèi)聯(lián)和非內(nèi)聯(lián)的編譯選項能夠?qū)е翷NK2001。如果
            創(chuàng)建C++庫時打開了函數(shù)內(nèi)聯(lián)(/Ob1或/Ob2),但是在描述該函數(shù)的相應(yīng)頭
            文件里卻關(guān)閉了函數(shù)內(nèi)聯(lián)(沒有inline關(guān)鍵字),這時將得到該錯誤信息。
            為避免該問題的發(fā)生,應(yīng)該在相應(yīng)的頭文件中用inline關(guān)鍵字標(biāo)志內(nèi)聯(lián)函數(shù)。
              8.不正確的/SUBSYSTEM或/ENTRY設(shè)置也能導(dǎo)致LNK2001。
              其實,產(chǎn)生LNK2001的原因還有很多,以上的原因只是一部分而已,對初
            學(xué)者來說這些就夠理解一陣子了。但是,分析錯誤原因的目的是為了避免錯
            誤的發(fā)生。LNK2001錯誤雖然比較困難,但是只要注意到了上述問題,還是能
            夠避免和予以解決的。

            posted on 2006-06-20 16:36 Bourne 閱讀(2488) 評論(2)  編輯 收藏 引用

            FeedBack:
            # re: 轉(zhuǎn)貼:鏈接錯誤LINK2001 2006-06-21 09:51 dudu
            不要在首頁轉(zhuǎn)載文章!  回復(fù)  更多評論
              
            # ZihH 2007-06-08 11:24 LiPe
            AmOooOooOoO...  回復(fù)  更多評論
              

            只有注冊用戶登錄后才能發(fā)表評論。
            網(wǎng)站導(dǎo)航: 博客園   IT新聞   BlogJava   博問   Chat2DB   管理


            久久久久亚洲精品无码网址| 久久精品国产99久久久古代| 亚洲狠狠综合久久| 精品久久久久久久久中文字幕| 国产精品久久精品| 久久久黄片| 久久亚洲国产成人精品性色| 亚洲欧美精品伊人久久| 久久国内免费视频| 久久成人精品视频| 无码人妻精品一区二区三区久久久 | 无码八A片人妻少妇久久| 亚洲国产欧美国产综合久久| 久久久久中文字幕| 久久久亚洲欧洲日产国码二区| 成人久久综合网| 欧美黑人激情性久久| 久久99国产精品久久| 久久精品国产亚洲AV香蕉| 2020最新久久久视精品爱 | 99久久中文字幕| 欧美噜噜久久久XXX| 久久久久久久免费视频| 精品无码久久久久久久动漫| 国产午夜精品久久久久免费视| 无码乱码观看精品久久| 国产精品青草久久久久福利99| 日产精品99久久久久久| 99久久这里只精品国产免费 | 国产69精品久久久久99| 久久久女人与动物群交毛片| 欧美久久一区二区三区| 狠狠色综合网站久久久久久久| 国产精品一区二区久久精品| 日韩av无码久久精品免费| 怡红院日本一道日本久久| 国内精品久久国产大陆| 国内精品久久久久久野外| 久久亚洲国产成人精品性色| 精品综合久久久久久888蜜芽| 无码专区久久综合久中文字幕|