• <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>
            SmartPtr
            本博客已搬至:http://www.cnblogs.com/baiyanhuang/
            posts - 29,comments - 176,trackbacks - 0
            By SmartPtr(http://www.shnenglu.com/SmartPtr/)

            這幾天工作時(shí)碰到一個(gè)C++的編譯錯(cuò)誤(我使用的是Visual C++ 7.0),說是有一個(gè)類重復(fù)定義,仔細(xì)想想我們的這個(gè)項(xiàng)目也是做了好幾個(gè)Release了, 內(nèi)部代碼應(yīng)該不會(huì)有這樣的低級(jí)錯(cuò)誤, 真把類型給重復(fù)定義了,檢查結(jié)果正如我預(yù)料的一樣。 就這樣, 我左右沒找到原因,被一個(gè)編譯錯(cuò)誤給卡在那里了。(在我的概念中, 程序錯(cuò)誤的等級(jí)為:編譯錯(cuò)誤->鏈接錯(cuò)誤->邏輯錯(cuò)誤, 此錯(cuò)誤屬于最低級(jí) )。這時(shí)我仔細(xì)看了一下錯(cuò)誤提示, 發(fā)現(xiàn)重復(fù)定義是由于從兩個(gè)不同的路徑包含了同一個(gè)頭文件而引起的,同事也建議從另外一個(gè)路徑打開工程試試, 這才慢慢發(fā)現(xiàn)了原因。這個(gè)原因可能有些拗口,而事實(shí)上要出現(xiàn)這種錯(cuò)誤也有些曲折 讓我從不同情況下的類型重定義來解釋一下吧。

            我總結(jié)的C++中類型重定義情況有三。

            1 沒有在文件頭加#pragma once指示符。

            Type1.h:  #pragma once的作用是保證本文件只被編譯一次,如果沒有在Type1.h中加這句話那么在main.cpp里面包含了兩次Type1.h 就相當(dāng)于在main.cpp里面定義了兩次Type類, 自然就是類型重定義了。

            //#pragma once
            class Type
            {  

            };

            Main.cpp:

            #include "Type1.h"
            #include 
            "Type1.h"
            int main(int argc, char *argv[])
            {
               
            return 1;
            }

             

            2 兩個(gè)不同的頭文件中定義了相同的類型(均有#pragma once

            Type1.h:Type2.h:Main.cpp:

            #pragma once
            class Type
            {

            };

             

            #pragma once
            class Type
            {     

            };

             

              這里main.cpp中同時(shí)包含了Type1.h, Type2.h兩個(gè)頭文件, 雖然其文件頭都有#pragma once,但因?yàn)槭遣煌奈募?/span> 預(yù)編譯器還是會(huì)兩次把Type類的定義放在Main.cpp中, 所以也會(huì)出現(xiàn)了重定義。

            #include "Type1.h"
            #include 
            "Type2.h"
            int main(int argc, char *argv[])
            {
               
            return 1;
            }

             

            3 從兩個(gè)不同的路徑包含了同一個(gè)頭文件

              前面兩種是比較常見, 也是比較容易解決的情況, 而這里要講的第三種情況, 比較少見, 而且一般出現(xiàn)在有虛擬映射盤的時(shí)候。(這樣才能做到從兩個(gè)不同的路徑包含同一個(gè)頭文件), 其他會(huì)在什么時(shí)候出現(xiàn), 我還沒想到, 知道的朋友頂一下:)。下面我來分析一下:
            1 VC工程在D:\Test目錄下。
            2 映射虛擬盤XD:\Test.
            不熟悉的網(wǎng)友可以按此操作: 開始->運(yùn)行->在運(yùn)行窗口輸入:cmd->cmd窗口輸入:
            Subst X: D:\Test->回車。
            3 該工程有文件Type1.h, main.cpp

            Type1.h:

            #pragma once
            class Type
            {

            };

            Main.cpp:

            main.cpp這樣包含了兩個(gè)頭文件, 從本質(zhì)上來講, 它們都對(duì)應(yīng)于物理盤D:\Test下的文件Type1.h, 是同一個(gè)文件。但在不同的操作下, VC對(duì)其有不同的解釋。#include "X:\Type1.h"用的是絕對(duì)路徑, 自然沒有什么異議, #include "Type1.h"卻有些變化:
            *假如我從D:\Test\下打開工程, 那么#include "Type1.h"其實(shí)就是#include "D:\Test\Type1.h"
            *假如從X:\下打開工程,那么#include "Type1.h"就解釋為#include "X:\Type1.h"

            #include "Type1.h"
            #include 
            "X:Type1.h"
            int main(int argc, char *argv[])
            {
               
            return 1
            ;
            }

                這里我們?cè)?/p>

            4 D:\Test下打開工程, 編譯, 出現(xiàn)類型Type重復(fù)定義錯(cuò)誤

            這種情況下,main.cpp預(yù)編譯為:

            Main.cpp:

            只保證本文件被編譯一次, 這里VC將其認(rèn)為是兩個(gè)不同的文件, 所以都要編譯, 出現(xiàn)編譯錯(cuò)誤自然也就不奇怪了。
               
            當(dāng)然, 這里如果從X:\ 下打開工程的話,VC就會(huì)認(rèn)為都是從X:\Type1.h下包含這個(gè)文件,#pragma once起到了作用, 也就不會(huì)出現(xiàn)類型重定義了

            #include "D:TestType1.h"
            #include 
            "X:Type1.h"
            int main(int argc, char *argv[])
            {
               
            return 1;
            }

              #pragma once

            總結(jié)

            我在VC7, VC8,Dev C++中都測試了第三種情況, 發(fā)現(xiàn)只有Dev C++是可以通過編譯的。這可能是微軟VC#pragma once還不夠智能吧,輕易的被Windows的虛擬盤給蒙蔽了雙眼, 看不到其本質(zhì)(只是猜測, 或許VC這么處理是有其他用意的)。

            因?yàn)樵谏源笠稽c(diǎn)的工程開發(fā)中, 我們一般都會(huì)用虛擬盤來方便工作, 一是訪問快捷,簡化了路徑, 二是因?yàn)槎嗳藚f(xié)同開發(fā),我們一般希望大家源代碼路徑相同,但我們不應(yīng)強(qiáng)制要求大家都把源代碼放死在某一目錄下, 這時(shí)把你放源代碼的路徑映射為一個(gè)虛擬盤(比如說統(tǒng)一為X:)就能把大家的代碼路徑統(tǒng)一起來了。但是另一方面,有了虛擬盤, 就為出現(xiàn)類型重定義提供了條件, 以下是我得出的兩個(gè)解決方法:

            1
            拋棄#pragma once使用古老但集穩(wěn)定性與移植性于一身的

            來保證頭文件只被編譯一次。這樣不管是包含兩個(gè)相同的文件,還是包含兩個(gè)不同的文件,或是包兩個(gè)文件相同但路徑不同的文件, 只要_XXX_H被定義過, 就不會(huì)再編譯那個(gè)編譯(但這里我們要保證_XXX_H的唯一性, 如果兩個(gè)不同的頭文件里用了同一_XXX_H,是會(huì)出問題的)

            #ifndef _XXX_H
            #define _XXX_H
            ...

            #endif

             

            2 在包含頭文件時(shí),不要使用絕對(duì)路徑, 哪怕那是虛擬盤的絕對(duì)路徑。

            posted on 2007-07-05 17:49 SmartPtr 閱讀(5865) 評(píng)論(5)  編輯 收藏 引用

            FeedBack:
            # re: C++中的類型重定義
            2007-07-05 23:08 | cpper
            學(xué)到了!!!!!  回復(fù)  更多評(píng)論
              
            # re: C++中的類型重定義
            2007-07-06 01:52 | 至尊拖鞋
            見識(shí)了,還沒用過虛擬盤映射功能的  回復(fù)  更多評(píng)論
              
            # re: C++中的類型重定義
            2007-07-06 14:32 | william
            也不一定用subst來做虛擬盤,如果是ntfs格式的話 其實(shí)做一個(gè)虛擬目錄比較好  回復(fù)  更多評(píng)論
              
            # re: C++中的類型重定義
            2007-07-08 01:32 | 天津大學(xué)計(jì)算機(jī)學(xué)院 常興龍
            總結(jié)得很不錯(cuò),在Symbian開發(fā)時(shí)會(huì)經(jīng)常用的虛擬路徑。  回復(fù)  更多評(píng)論
              
            # re: C++中的類型重定義
            2007-07-12 15:35 | Rick

            VC是用MS自己的Compiler,估計(jì)這個(gè)Compiler是采用頭文件的絕對(duì)路徑來作為唯一標(biāo)識(shí)的,所以對(duì)于同一個(gè)文件通過不同的方式(本地和虛擬盤)來include,VC視作為兩個(gè)不同的頭文件。
            而DevC++采用GCC的Compiler,這個(gè)Compiler發(fā)現(xiàn)兩個(gè)同名的頭文件(不管絕對(duì)路徑和這兩個(gè)文件是否其實(shí)是一個(gè)文件)被include后,會(huì)檢查這兩個(gè)頭文件的修改時(shí)間是否一致。如果一致,則認(rèn)為這兩個(gè)頭文件是一樣的,并且頭文件包含“#pragma once”的話就只解析一次,不會(huì)報(bào)錯(cuò)。否則,兩個(gè)文件修改時(shí)間不一樣,那會(huì)認(rèn)為是兩個(gè)不同的文件(不管這兩個(gè)文件的內(nèi)容是否一樣),所以解析的時(shí)候會(huì)報(bào)重復(fù)定義錯(cuò)誤。
              回復(fù)  更多評(píng)論
              

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


            久久精品女人天堂AV麻| 99久久国产综合精品五月天喷水| 久久精品一本到99热免费| 蜜桃麻豆WWW久久囤产精品| 97久久精品无码一区二区天美 | 久久久久久久91精品免费观看| 亚洲精品无码久久千人斩| 久久久91人妻无码精品蜜桃HD | 伊人久久大香线焦综合四虎| 无码任你躁久久久久久老妇| AV狠狠色丁香婷婷综合久久| 无码国内精品久久综合88| 国产69精品久久久久9999| 久久婷婷国产综合精品| 狠狠色丁香久久婷婷综合图片| 国产成人久久精品二区三区| 少妇人妻88久久中文字幕| 亚洲午夜精品久久久久久浪潮| 国产精品一区二区久久 | 成人久久久观看免费毛片| 人妻无码久久精品| 久久精品国产欧美日韩| 精品久久久久久国产| 久久久久亚洲AV无码永不| 99精品国产99久久久久久97| 国产免费久久精品99re丫y| 人人狠狠综合久久亚洲| 四虎久久影院| 无码8090精品久久一区| 要久久爱在线免费观看| 久久久久一级精品亚洲国产成人综合AV区| 亚洲国产精品久久久久久| 日本精品久久久中文字幕| 欧美精品一本久久男人的天堂| 精品国际久久久久999波多野| 亚洲精品乱码久久久久久蜜桃图片 | 精品久久8x国产免费观看| 99国产精品久久久久久久成人热| 亚洲精品无码久久千人斩| 久久精品aⅴ无码中文字字幕不卡| 亚洲国产另类久久久精品黑人 |