基于C++類型重定義的使用詳解

更新時間：2013年05月16日 10:47:17 作者：

本篇文章是對C++中類型重定義的使用進行了詳細的分析介紹，需要的朋友參考下

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

復制代碼代碼如下:

Type1.h:
//#pragma once
class Type
{
};
Main.cpp:
#include "Type1.h"
#include "Type1.h"
int main(int argc, char *argv[])
{   
return 1;
}

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

二、兩個不同的頭文件中定義了相同的類型（均有#pragma once）

復制代碼代碼如下:

Type1.h:
#pragma once
class Type
{
};
Type2.h:
#pragma once
class Type
{
};
Main.cpp:
#include "Type1.h"
#include "Type2.h"
int main(int argc, char *argv[])
{   
return 1;
}

這里main.cpp中同時包含了Type1.h, Type2.h兩個頭文件，雖然其文件頭都有#pragma once，但因為是不同的文件，預編譯器還是會兩次把Type類的定義放在Main.cpp中，所以也會出現(xiàn)了重定義。

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

復制代碼代碼如下:

Type1.h:
#pragma once
class Type{};
Main.cpp:
#include "Type1.h"
#include "X:\Type1.h"
int main(int argc, char *argv[])
{   
return 1;
}

這里我們在main.cpp這樣包含了兩個頭文件，從本質(zhì)上來講，它們都對應于物理盤D:\Test下的文件Type1.h, 是同一個文件。但在不同的操作下， VC對其有不同的解釋。#include "X:\Type1.h"用的是絕對路徑，自然沒有什么異議，但#include "Type1.h"卻有些變化:
•假如我從D:\Test\下打開工程，那么#include "Type1.h"其實就是#include "D:\Test\Type1.h"
•假如從X:\下打開工程，那么#include "Type1.h"就解釋為#include "X:\Type1.h"
4）在D:\Test下打開工程，編譯，出現(xiàn)類型Type重復定義錯誤
這種情況下，main.cpp預編譯為:

復制代碼代碼如下:

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

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

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

因為在稍大一點的工程開發(fā)中，我們一般都會用虛擬盤來方便工作，一是訪問快捷，簡化了路徑，二是因為多人協(xié)同開發(fā)，我們一般希望大家源代碼路徑相同，但我們不應強制要求大家都把源代碼放死在某一目錄下，這時把你放源代碼的路徑映射為一個虛擬盤（比如說統(tǒng)一為X:）就能把大家的代碼路徑統(tǒng)一起來了。但是另一方面，有了虛擬盤，就為出現(xiàn)類型重定義提供了條件，以下是我得出的兩個解決方法：
1）拋棄#pragma once使用古老但集穩(wěn)定性與移植性于一身的

復制代碼代碼如下:

#ifndef _XXX_H
#define _XXX_H
//...#endif

來保證頭文件只被編譯一次。這樣不管是包含兩個相同的文件，還是包含兩個不同的文件，或是包含兩個文件相同但路徑不同的文件，只要_XXX_H被定義過，就不會再編譯那個編譯(但這里我們要保證_XXX_H的唯一性，如果兩個不同的頭文件里用了同一_XXX_H,是會出問題的)
2）在包含頭文件時，不要使用絕對路徑，哪怕那是虛擬盤的絕對路徑。

您可能感興趣的文章: