今天找了個解析xml的開源C++項目tinyxml，按照網上的說法去編譯，但是一直編譯不通過，“無法打開頭文件tinyxml.h”，但是明明我在工程底下有了這個文件，對于我這種初學C++的人來說我并不知道頭文件和源文件到底什么關系（不像java的類文件），不過最終還是解決了這個問題。

　　 一、源文件如何根據#include來關聯頭文件

　　1，系統自帶的頭文件用尖括號括起來，這樣編譯器會在系統文件目錄下查找。

　　 #include

　　 2，用戶自定義的文件用雙引號括起來，編譯器首先會在用戶目錄下查找，然后在到C++安裝目錄（比如VC中可以指定和修改庫文件查找路徑，Unix和Linux中可以通過環境變量來設定）中查找，最后在系統文件中查找。

　　 #include “"xxx.h”（我一直以為””和<>沒什么區別，但是tinyxml.h是非系統下的都文件，所以要用””）

　　 二、頭文件如何來關聯源文件

　　這個問題實際上是說，已知頭文件“a.h”聲明了一系列函數，“b.cpp”中實現了這些函數，那么如果我想在“c.cpp”中使用“a.h”中聲明的這些在“b.cpp”中實現的函數，通常都是在“c.cpp”中使用#include “a.h”,那么c.cpp是怎樣找到b.cpp中的實現呢？

　　 其實.cpp和.h文件名稱沒有任何直接關系，很多編譯器都可以接受其他擴展名。比如偶現在看到偶們公司的源代碼，.cpp文件由.cc文件替代了。

　　 在Turbo C中，采用命令行方式進行編譯，命令行參數為文件的名稱，默認的是.cpp和.h，但是也可以自定義為.xxx等等。

　　 譚浩強老師的《C程序設計》一書中提到，編譯器預處理時，要對#include命令進行“文件包含處理”：將file2.c的全部內容復制到#include “file2.c”處。這也正說明了，為什么很多編譯器并不care到底這個文件的后綴名是什么----因為#include預處理就是完成了一個“復制并插入代碼&rdquo;的工作。

　　 編譯的時候，并不會去找b.cpp文件中的函數實現，只有在link的時候才進行這個工作。我們在b.cpp或c.cpp中用#include “a.h”實際上是引入相關聲明，使得編譯可以通過，程序并不關心實現是在哪里，是怎么實現的。源文件編譯后成生了目標文件（.o或.obj文件），目標文件中，這些函數和變量就視作一個個符號。在link的時候，需要在makefile里面說明需要連接哪個.o或.obj文件（在這里是b.cpp生成的.o或.obj文件），此時，連接器會去這個.o或.obj文件中找在b.cpp中實現的函數，再把他們build到makefile中指定的那個可以執行文件中。

　　 在Unix下，甚至可以不在源文件中包括頭文件，只需要在makefile中指名即可（不過這樣大大降低了程序可讀性，是個不好的習慣哦^_^）。在VC中，一幫情況下不需要自己寫makefile，只需要將需要的文件都包括在project中，VC會自動幫你把makefile寫好。

　　 通常，編譯器會在每個.o或.obj文件中都去找一下所需要的符號，而不是只在某個文件中找或者說找到一個就不找了。因此，如果在幾個不同文件中實現了同一個函數，或者定義了同一個全局變量，鏈接的時候就會提示“redefined”。今天找了個解析xml的開源C++項目tinyxml，按照網上的說法去編譯，但是一直編譯不通過，“無法打開頭文件tinyxml.h”，但是明明我在工程底下有了這個文件，對于我這種初學C++的人來說我并不知道頭文件和源文件到底什么關系（不像java的類文件），不過最終還是解決了這個問題。

　　 一、源文件如何根據#include來關聯頭文件

　　1，系統自帶的頭文件用尖括號括起來，這樣編譯器會在系統文件目錄下查找。

　　 #include

　　 2，用戶自定義的文件用雙引號括起來，編譯器首先會在用戶目錄下查找，然后在到C++安裝目錄（比如VC中可以指定和修改庫文件查找路徑，Unix和Linux中可以通過環境變量來設定）中查找，最后在系統文件中查找。

　　 #include “"xxx.h”（我一直以為”&rdquo;和<>沒什么區別，但是tinyxml.h是非系統下的都文件，所以要用””）

　　 二、頭文件如何來關聯源文件

　　這個問題實際上是說，已知頭文件“a.h”聲明了一系列函數，“b.cpp&rdquo;中實現了這些函數，那么如果我想在“c.cpp”中使用“a.h”中聲明的這些在“b.cpp”中實現的函數，通常都是在“c.cpp”中使用#include “a.h”,那么c.cpp是怎樣找到b.cpp中的實現呢？

　　 其實.cpp和.h文件名稱沒有任何直接關系，很多編譯器都可以接受其他擴展名。比如偶現在看到偶們公司的源代碼，.cpp文件由.cc文件替代了。

　　 在Turbo C中，采用命令行方式進行編譯，命令行參數為文件的名稱，默認的是.cpp和.h，但是也可以自定義為.xxx等等。

　　 譚浩強老師的《C程序設計》一書中提到，編譯器預處理時，要對#include命令進行“文件包含處理”：將file2.c的全部內容復制到#include “file2.c”處。這也正說明了，為什么很多編譯器并不care到底這個文件的后綴名是什么----因為#include預處理就是完成了一個“復制并插入代碼”的工作。

　　 編譯的時候，并不會去找b.cpp文件中的函數實現，只有在link的時候才進行這個工作。我們在b.cpp或c.cpp中用#include “a.h”實際上是引入相關聲明，使得編譯可以通過，程序并不關心實現是在哪里，是怎么實現的。源文件編譯后成生了目標文件（.o或.obj文件），目標文件中，這些函數和變量就視作一個個符號。在link的時候，需要在makefile里面說明需要連接哪個.o或.obj文件（在這里是b.cpp生成的.o或.obj文件），此時，連接器會去這個.o或.obj文件中找在b.cpp中實現的函數，再把他們build到makefile中指定的那個可以執行文件中。

　　 在Unix下，甚至可以不在源文件中包括頭文件，只需要在makefile中指名即可（不過這樣大大降低了程序可讀性，是個不好的習慣哦^_^）。在VC中，一幫情況下不需要自己寫makefile，只需要將需要的文件都包括在project中，VC會自動幫你把makefile寫好。

　　 通常，編譯器會在每個.o或.obj文件中都去找一下所需要的符號，而不是只在某個文件中找或者說找到一個就不找了。因此，如果在幾個不同文件中實現了同一個函數，或者定義了同一個全局變量，鏈接的時候就會提示&ldquo;redefined”。

　　一、聲明與定義的區分：

　　 一個聲明就是一個定義，除非 ：

　　 聲明：引入名稱

　　 定義：引入實體

　　 它聲明了一個沒有詳細說明函數體的函數

　　 它包含一個extern定義符且沒有初始化函數或函數體

　　 它是一個包含在一個類定義之內的靜態類數據成員的聲明，它必須在最終程序的某處準確的定義一次

　　 它是一個類名聲明，如class test;

　　 它是一個typedef聲明。

　　 言外之意：

　　 1、類的聲明也就是定義

　　 2、同時賦初值的聲明也就是定義，如

　　 3、類非靜態數據成員的聲明也就是定義？？？

　　 4、類的所有成員函數的聲明也就是定義

　　 一個定義就是一個聲明，除非：

　　 1.它定義的是一個靜態數據成員

　　 2.它定義了一個非內聯成員函數

　　 內部連接和外部連接：

　　 編譯時每個文件會被編譯成一個含有必要信息的源文件(又叫編譯單元)，然后編譯單元會聯結成一個和族文件同名的.o文件，.o文件把不同的編譯單元中產生的符號聯系起來，構成一個可執行文件。有兩種截然不同的鏈接：內部的和外部的，將這些編譯單元聯系起來。

　　 內部連接：對這個定義的訪問被局限在當前編譯單元，其他編譯單元無法訪問。

　　 外部連接：可被其他單元訪問，因此名稱在整個執行文件中必須唯一。

　　 類的定義（同時也是聲明），enum，struct，都是內部連接，內聯函數，靜態的非類成員數據也是

　　 typedef聲明的類型也是內聯結。

　　 非內聯成員函數（包括靜態成員）有外部連接，非內聯函數，非靜態自由函數（非類的成員函數）也是外連接。

　　 聲明只對當前編譯單元有用，他們不會影響到.o文件，

　　 .h文件，由于該文件會被其他.cpp文件包含，但由于聲明只是對當前編譯單元有效，是不會將符號引入.o文件，所以該文件不能含有任何外部連接的符號（數據成員和函數）的定義。 一般情況下也不要包含內連接符號的定義。

綜上所訴：

　　 .h文件中能包含：

　　 類成員數據的聲明，但不能賦值

　　 類靜態數據成員的定義和賦值，但不建議，只是個聲明就好。

　　 類的成員函數的聲明

　　 非類成員函數的聲明

　　 常數的定義：如：const int a=5;

　　 靜態函數的定義

　　 類的內聯函數的定義

　　 不能包含：

　　 1． 所有非靜態變量（不是類的數據成員）的聲明

　　 2。 默認命名空間聲明不要放在頭文件，using namespace  std;等應放在.cpp中，在.h文件中使用std::string