c++模板類

理解編譯器的編譯模板過程

如何組織編寫模板程式

前言
常遇到詢問使用模板到底是否容易的問題，我的回答是：“模板的使用是容易的，但組織編寫卻不容易”。看看我們幾乎每天都能遇到的模板類吧，如STL, ATL, WTL, 以及Boost的模板類，都能體會到這樣的滋味：介面簡單，操作複雜。

我在5年前開始使用模板，那時我看到了MFC的容器類。直到去年我還沒有必要自己編寫模板類。可是在我需要自己編寫模板類時，我首先遇到的事實卻是“傳統”程式設計方法(在*.h檔案宣告，在*.cpp檔案中定義)不能用於模板。於是我花費一些時間來了解問題所在及其解決方法。

本文物件是那些熟悉模板但還沒有很多編寫模板經驗的程式設計師。本文只涉及模板類，未涉及模板函式。但論述的原則對於二者是一樣的。

問題的產生
通過下例來說明問題。例如在array.h檔案中有模板類array：
// array.h
template <typename T, int SIZE>
class array
{
    T data_[SIZE];
    array (const array& other);
    const array& operator = (const array& other);
public:
    array(){};
    T& operator[](int i) {return data_[i];}
    const T& get_elem (int i) const {return data_[i];}
    void set_elem(int i, const T& value) {data_[i] = value;}
    operator T*() {return data_;}      
};            
            
然後在main.cpp檔案中的主函式中使用上述模板：
// main.cpp
#include "array.h"

int main(void)
{
array<int, 50> intArray;
intArray.set_elem(0, 2);
int firstElem = intArray.get_elem(0);
int* begin = intArray;
}
        
這時編譯和執行都是正常的。程式先建立一個含有50個整數的陣列，然後設定陣列的第一個元素值為2，再讀取第一個元素值，最後將指標指向陣列起點。

但如果用傳統程式設計方式來編寫會發生什麼事呢？我們來看看：

將array.h檔案分裂成為array.h和array.cpp二個檔案(main.cpp保持不變)
// array.h        
template <typename T, int SIZE>
class array
{
      T data_[SIZE];
      array (const array& other);
      const array& operator = (const array& other);
  public:
      array(){};
      T& operator[](int i);
      const T& get_elem (int i) const;
      void set_elem(int i, const T& value);
      operator T*();      
};        
    
// array.cpp
#include "array.h"

template<typename T, int SIZE> T& array<T, SIZE>::operator [](int i)
    {
    return data_[i];
    }

template<typename T, int SIZE> const T& array<T, SIZE>::get_elem(int i) const
    {
    return data_[i];
    }

template<typename T, int SIZE> void array<T, SIZE>::set_elem(int i, const T& value)
    {
    data_[i] = value;
    }
template<typename T, int SIZE> array<T, SIZE>::operator T*()
    {
    return data_;
    }
        
編譯時會出現3個錯誤。問題出來了：
  為什麼錯誤都出現在第一個地方？
  為什麼只有3個連結出錯？array.cpp中有4個成員函式。
  
要回答上面的問題，就要深入瞭解模板的例項化過程。

模板例項化
程式設計師在使用模板類時最常犯的錯誤是將模板類視為某種資料型別。所謂型別參量化(parameterized types)這樣的術語導致了這種誤解。模板當然不是資料型別，模板就是模板，恰如其名：

  編譯器使用模板，通過更換模板引數來建立資料型別。這個過程就是模板例項化(Instantiation)。
  從模板類建立得到的型別稱之為特例(specialization)。 
  模板例項化取決於編譯器能夠找到可用程式碼來建立特例(稱之為例項化要素，
  point of instantiation)。
  要建立特例，編譯器不但要看到模板的宣告，還要看到模板的定義。
  模板例項化過程是遲鈍的，即只能用函式的定義來實現例項化。

再回頭看上面的例子，可以知道array是一個模板，array<int, 50>是一個模板例項 - 一個型別。從array建立array<int, 50>的過程就是例項化過程。例項化要素體現在main.cpp檔案中。如果按照傳統方式，編譯器在array.h檔案中看到了模板的宣告，但沒有模板的定義，這樣編譯器就不能建立型別array<int, 50>。但這時並不出錯，因為編譯器認為模板定義在其它檔案中，就把問題留給連結程式處理。

現在，編譯array.cpp時會發生什麼問題呢？編譯器可以解析模板定義並檢查語法，但不能生成成員函式的程式碼。它無法生成程式碼，因為要生成程式碼，需要知道模板引數，即需要一個型別，而不是模板本身。

這樣，連結程式在main.cpp 或 array.cpp中都找不到array<int, 50>的定義，於是報出無定義成員的錯誤。

至此，我們回答了第一個問題。但還有第二個問題，在array.cpp中有4個成員函式，連結器為什麼只報了3個錯誤？回答是：例項化的惰性導致這種現象。在main.cpp中還沒有用上operator[]，編譯器還沒有例項化它的定義。

解決方法
認識了問題，就能夠解決問題：
  在例項化要素中讓編譯器看到模板定義。
  用另外的檔案來顯式地例項化型別，這樣連結器就能看到該型別。
  使用export關鍵字。

前二種方法通常稱為包含模式，第三種方法則稱為分離模式。

第一種方法意味著在使用模板的轉換檔案中不但要包含模板宣告檔案，還要包含模板定義檔案。在上例中，就是第一個示例，在array.h中用行內函式定義了所有的成員函式。或者在main.cpp檔案中也包含進array.cpp檔案。這樣編譯器就能看到模板的宣告和定義，並由此生成array<int, 50>例項。這樣做的缺點是編譯檔案會變得很大，顯然要降低編譯和連結速度。

第二種方法，通過顯式的模板例項化得到型別。最好將所有的顯式例項化過程安放在另外的檔案中。在本例中，可以建立一個新檔案templateinstantiations.cpp：
// templateinstantiations.cpp                
#include "array.cpp"

template class array <int, 50>; // 顯式例項化
        
array<int, 50>型別不是在main.cpp中產生，而是在templateinstantiations.cpp中產生。這樣連結器就能夠找到它的定義。用這種方法，不會產生巨大的標頭檔案，加快編譯速度。而且標頭檔案本身也顯得更加“乾淨”和更具有可讀性。但這個方法不能得到惰性例項化的好處，即它將顯式地生成所有的成員函式。另外還要維護templateinstantiations.cpp檔案。

第三種方法是在模板定義中使用export關鍵字，剩下的事就讓編譯器去自行處理了。當我在
Stroustrup的書中讀到export時，感到非常興奮。但很快就發現VC 6.0不支援它，後來又發現根本沒有編譯器能夠支援這個關鍵字(第一個支援它的編譯器要在2002年底才問世)。自那以後，我閱讀了不少關於export的文章，瞭解到它幾乎不能解決用包含模式能夠解決的問題。欲知更多的export關鍵字，建議讀讀Herb Sutter撰寫的文章。

結論
要開發模板庫，就要知道模板類不是所謂的"原始型別"，要用其它的程式設計思路。本文目的不是要嚇唬那些想進行模板程式設計的程式設計師。恰恰相反，是要提醒他們避免犯下開始模板程式設計時都會出現的錯誤。

 

//////////////////////////////
http://www.cnblogs.com/xgchang/archive/2004/11/12/63139.aspx
甚至是在定義非行內函數時，模板的標頭檔案中也會放置所有的宣告和定義。這似乎違背了通常的標頭檔案規則：“不要在分配儲存空間前放置任何東西”，這條規則是為了防止在連線時的多重定義錯誤。但模板定義很特殊。由template<...>處理的任何東西都意味著編譯器在當時不為它分配儲存空間，它一直出於等待狀態直到被一個模板例項告知。在編譯器和聯結器的某一處，有一機制能去掉模板的多重定義，所以為了容易使用，幾乎總是在標頭檔案中放置全部的模板宣告和定義。

為什麼C++編譯器不能支援對模板的分離式編譯 
劉未鵬(pongba) /文

首先，C++標準中提到，一個編譯單元[translation unit]是指一個.cpp檔案以及它所include的所有.h檔案，.h檔案裡的程式碼將會被擴充套件到包含它的.cpp檔案裡，然後編譯器編譯該.cpp檔案為一個.obj檔案，後者擁有PE[Portable Executable,即windows可執行檔案]檔案格式，並且本身包含的就已經是二進位制碼，但是，不一定能夠執行，因為並不保證其中一定有main函式。當編譯器將一個工程裡的所有.cpp檔案以分離的方式編譯完畢後，再由聯結器(linker)進行連線成為一個.exe檔案。 
舉個例子： 
//---------------test.h-------------------// 
void f();//這裡宣告一個函式f 
//---------------test.cpp--------------// 
#include”test.h” 
void f() 
{ 
…//do something 
} //這裡實現出test.h中宣告的f函式 
//---------------main.cpp--------------// 
#include”test.h” 
int main() 
{ 
f(); //呼叫f，f具有外部連線型別 
} 
在這個例子中，test. cpp和main.cpp各被編譯成為不同的.obj檔案[姑且命名為test.obj和main.obj]，在main.cpp中，呼叫了f函式，然而當編譯器編譯main.cpp時，它所僅僅知道的只是main.cpp中所包含的test.h檔案中的一個關於void f();的宣告，所以，編譯器將這裡的f看作外部連線型別，即認為它的函式實現程式碼在另一個.obj檔案中，本例也就是test.obj，也就是說，main.obj中實際沒有關於f函式的哪怕一行二進位制程式碼，而這些程式碼實際存在於test.cpp所編譯成的test.obj中。在main.obj中對f的呼叫只會生成一行call指令，像這樣： 
call f [C++中這個名字當然是經過mangling[處理]過的] 
在編譯時，這個call指令顯然是錯誤的，因為main.obj中並無一行f的實現程式碼。那怎麼辦呢？這就是聯結器的任務，聯結器負責在其它的.obj中[本例為test.obj]尋找f的實現程式碼，找到以後將call f這個指令的呼叫地址換成實際的f的函式進入點地址。需要注意的是：聯結器實際上將工程裡的.obj“連線”成了一個.exe檔案，而它最關鍵的任務就是上面說的，尋找一個外部連線符號在另一個.obj中的地址，然後替換原來的“虛假”地址。 
這個過程如果說的更深入就是： 
call f這行指令其實並不是這樣的，它實際上是所謂的stub，也就是一個 
jmp 0x23423[這個地址可能是任意的，然而關鍵是這個地址上有一行指令來進行真正的call f動作。也就是說，這個.obj檔案裡面所有對f的呼叫都jmp向同一個地址，在後者那兒才真正”call”f。這樣做的好處就是聯結器修改地址時只要對後者的call XXX地址作改動就行了。但是，聯結器是如何找到f的實際地址的呢[在本例中這處於test.obj中]，因為.obj於.exe的格式都是一樣的，在這樣的檔案中有一個符號匯入表和符號匯出表[import table和export table]其中將所有符號和它們的地址關聯起來。這樣聯結器只要在test.obj的符號匯出表中尋找符號f[當然C++對f作了mangling]的地址就行了，然後作一些偏移量處理後[因為是將兩個.obj檔案合併，當然地址會有一定的偏移，這個聯結器清楚]寫入main.obj中的符號匯入表中f所佔有的那一項。 
這就是大概的過程。其中關鍵就是： 
編譯main.cpp時，編譯器不知道f的實現，所有當碰到對它的呼叫時只是給出一個指示，指示聯結器應該為它尋找f的實現體。這也就是說main.obj中沒有關於f的任何一行二進位制程式碼。 
編譯test.cpp時，編譯器找到了f的實現。於是乎f的實現[二進位制程式碼]出現在test.obj裡。 
連線時，聯結器在test.obj中找到f的實現程式碼[二進位制]的地址[通過符號匯出表]。然後將main.obj中懸而未決的call XXX地址改成f實際的地址。 
完成。

然而，對於模板，你知道，模板函式的程式碼其實並不能直接編譯成二進位制程式碼，其中要有一個“具現化”的過程。舉個例子： 
//----------main.cpp------// 
template<class T> 
void f(T t) 
{} 
int main() 
{ 
…//do something 
f(10); //call f<int> 編譯器在這裡決定給f一個f<int>的具現體 
…//do other thing 
} 
也就是說，如果你在main.cpp檔案中沒有呼叫過f，f也就得不到具現，從而main.obj中也就沒有關於f的任意一行二進位制程式碼！！如果你這樣呼叫了： 
f(10); //f<int>得以具現化出來 
f(10.0); //f<double>得以具現化出來 
這樣main.obj中也就有了f<int>,f<double>兩個函式的二進位制程式碼段。以此類推。 
然而具現化要求編譯器知道模板的定義，不是嗎？ 
看下面的例子：[將模板和它的實現分離] 
//-------------test.h----------------// 
template<class T> 
class A 
{ 
public: 
void f(); //這裡只是個宣告 
}; 
//---------------test.cpp-------------// 
#include”test.h” 
template<class T> 
void A<T>::f() //模板的實現，但注意：不是具現 
{ 
…//do something 
} 
//---------------main.cpp---------------// 
#include”test.h” 
int main() 
{ 
A<int> a; 
a. f(); //編譯器在這裡並不知道A<int>::f的定義，因為它不在test.h裡面 
//於是編譯器只好寄希望於聯結器，希望它能夠在其他.obj裡面找到 
//A<int>::f的實現體,在本例中就是test.obj，然而，後者中真有A<int>::f的 
//二進位制程式碼嗎？NO！！！因為C++標準明確表示，當一個模板不被用到的時 
//侯它就不該被具現出來，test.cpp中用到了A<int>::f了嗎？沒有！！所以實 
//際上test.cpp編譯出來的test.obj檔案中關於A::f的一行二進位制程式碼也沒有 
//於是聯結器就傻眼了，只好給出一個連線錯誤 
//但是，如果在test.cpp中寫一個函式，其中呼叫A<int>::f，則編譯器會將其//具現出來，因為在這個點上[test.cpp中]，編譯器知道模板的定義，所以能//夠具現化，於是，test.obj的符號匯出表中就有了A<int>::f這個符號的地 
//址，於是聯結器就能夠完成任務。 
}

關鍵是：在分離式編譯的環境下，編譯器編譯某一個.cpp檔案時並不知道另一個.cpp檔案的存在，也不會去查詢[當遇到未決符號時它會寄希望於聯結器]。這種模式在沒有模板的情況下執行良好，但遇到模板時就傻眼了，因為模板僅在需要的時候才會具現化出來，所以，當編譯器只看到模板的宣告時，它不能具現化該模板，只能建立一個具有外部連線的符號並期待聯結器能夠將符號的地址決議出來。然而當實現該模板的.cpp檔案中沒有用到模板的具現體時，編譯器懶得去具現，所以，整個工程的.obj中就找不到一行模板具現體的二進位制程式碼，於是聯結器也黔

 

 

/////////////////////////////////
http://dev.csdn.net/develop/article/19/19587.shtm
 C++模板程式碼的組織方式 ——包含模式（Inclusion Model）     選擇自 sam1111 的 Blog  
關鍵字   Template Inclusion Model 
出處   C++ Template: The Complete Guide

說明：本文譯自《C++ Template: The Complete Guide》一書的第6章中的部分內容。最近看到C++論壇上常有關於模板的包含模式的帖子，聯想到自己初學模板時，也為類似的問題困惑過，因此翻譯此文，希望對初學者有所幫助。

模板程式碼有幾種不同的組織方式，本文介紹其中最流行的一種方式：包含模式。

連結錯誤

大多數C/C++程式設計師向下面這樣組織他們的非模板程式碼：

         ·類和其他型別全部放在標頭檔案中，這些標頭檔案具有.hpp（或者.H, .h, .hh, .hxx）副檔名。

         ·對於全域性變數和（非內聯）函式，只有宣告放在標頭檔案中，而定義放在點C檔案中，這些檔案具有.cpp（或者.C, .c, .cc, .cxx）副檔名。
 

這種組織方式工作的很好：它使得在程式設計時可以方便地訪問所需的型別定義，並且避免了來自連結器的“變數或函式重複定義”的錯誤。
 

由於以上組織方式約定的影響，模板程式設計新手往往會犯一個同樣的錯誤。下面這一小段程式反映了這種錯誤。就像對待“普通程式碼”那樣，我們在標頭檔案中定義模板：
 

// basics/myfirst.hpp 

#ifndef MYFIRST_HPP 
#define MYFIRST_HPP 

// declaration of template

template <typename T>

void print_typeof (T const&);

#endif // MYFIRST_HPP

 

print_typeof()宣告瞭一個簡單的輔助函式用來列印一些型別資訊。函式的定義放在點C檔案中：

// basics/myfirst.cpp

#include <iostream>

#include <typeinfo>

#include "myfirst.hpp" 
 

// implementation/definition of template

template <typename T> 
void print_typeof (T const& x) 
{

    std::cout << typeid(x).name() << std::endl;

}

 

這個例子使用typeid操作符來列印一個字串，這個字串描述了傳入的引數的型別資訊。

最後，我們在另外一個點C檔案中使用我們的模板，在這個檔案中模板宣告被#include：

// basics/myfirstmain.cpp 

#include "myfirst.hpp" 

// use of the template

int main() 
{

    double ice = 3.0; 
    print_typeof(ice);  // call function template for type double

}

大部分C++編譯器（Compiler）很可能會接受這個程式，沒有任何問題，但是連結器（Linker）大概會報告一個錯誤，指出缺少函式print_typeof()的定義。

這個錯誤的原因在於，模板函式print_typeof()的定義還沒有被具現化（instantiate）。為了具現化一個模板，編譯器必須知道哪一個定義應該被具現化，以及使用什麼樣的模板引數來具現化。不幸的是，在前面的例子中，這兩組資訊存在於分開編譯的不同檔案中。因此，當我們的編譯器看到對print_typeof()的呼叫，但是沒有看到此函式為double型別具現化的定義時，它只是假設這樣的定義在別處提供，並且建立一個那個定義的引用（連結器使用此引用解析）。另一方面，當編譯器處理myfirst.cpp時，該檔案並沒有任何指示表明它必須為它所包含的特殊引數具現化模板定義。

標頭檔案中的模板

解決上面這個問題的通用解法是，採用與我們使用巨集或者行內函數相同的方法：我們將模板的定義包含進宣告模板的標頭檔案中。對於我們的例子，我們可以通過將#include "myfirst.cpp"新增到myfirst.hpp檔案尾部，或者在每一個使用我們的模板的點C檔案中包含myfirst.cpp檔案，來達到目的。當然，還有第三種方法，就是刪掉myfirst.cpp檔案，並重寫myfirst.hpp檔案，使它包含所有的模板宣告與定義：

// basics/myfirst2.hpp

#ifndef MYFIRST_HPP 
#define MYFIRST_HPP 

#include <iostream> 
#include <typeinfo> 
 

// declaration of template 
template <typename T> 
void print_typeof (T const&); 

// implementation/definition of template 
template <typename T> 
void print_typeof (T const& x) 
{

    std::cout << typeid(x).name() << std::endl;

}

#endif // MYFIRST_HPP

 

這種組織模板程式碼的方式就稱作包含模式。經過這樣的調整，你會發現我們的程式已經能夠正確編譯、連結、執行了。

從這個方法中我們可以得到一些觀察結果。最值得注意的一點是，這個方法在相當程度上增加了包含myfirst.hpp的開銷。在這個例子中，這種開銷並不是由模板定義自身的尺寸引起的，而是由這樣一個事實引起的，即我們必須包含我們的模板用到的標頭檔案，在這個例子中是<iostream>和<typeinfo>。你會發現這最終導致了成千上萬行的程式碼，因為諸如<iostream>這樣的標頭檔案也包含了和我們類似的模板定義。

這在實踐中確實是一個問題，因為它增加了編譯器在編譯一個實際程式時所需的時間。我們因此會在以後的章節中驗證其他一些可能的方法來解決這個問題。但無論如何，現實世界中的程式花一小時來編譯連結已經是快的了（我們曾經遇到過花費數天時間來從原始碼編譯的程式）。

拋開編譯時間不談，我們強烈建議如果可能儘量按照包含模式組織模板程式碼。

另一個觀察結果是，非內聯模板函式與行內函數和巨集的最重要的不同在於：它並不會在呼叫端展開。相反，當模板函式被具現化時，會產生此函式的一個新的拷貝。由於這是一個自動的過程，編譯器也許會在不同的檔案中產生兩個相同的拷貝，從而引起連結器報告一個錯誤。理論上，我們並不關心這一點：這是編譯器設計者應當關心的事情。實際上，大多數時候一切都運轉正常，我們根本就不用處理這種狀況。然而，對於那些需要建立自己的庫的大型專案，這個問題偶爾會顯現出來。
 

最後，需要指出的是，在我們的例子中，應用於普通模板函式的方法同樣適用於模板類的成員函式和靜態資料成員，以及模板成員函式。

 

本文來自CSDN部落格，轉載請標明出處：http://blog.csdn.net/look01/archive/2008/11/05/3228134.aspx