泛型是C++中的重要特性。據(jù)說，已經(jīng)在C++社區(qū)中已經(jīng)取代面向?qū)ο蟪蔀镃++的主要編程泛型。STL和boost庫等都廣泛使用了泛型。
template<typename T> class Manage{…全部內(nèi)聯(lián)函數(shù)實現(xiàn)！}; 函數(shù)模版的定義,形如：
template<typename SequenceT>
void trim(SequenceT &, const std::locale & = std::locale());
模板的特化
模板類的特化1）首先定義基泛型：
template<typename T> class Manage{…全部內(nèi)聯(lián)函數(shù)實現(xiàn)！};
2)然后定義特化的泛型：
#include 上面基泛型的文件
template<> class Manage<B>
{…全部內(nèi)聯(lián)函數(shù)實現(xiàn)！};
特化的泛型必須自己實現(xiàn)所有基泛型定義的成員函數(shù)和靜態(tài)成員。
模板類的成員函數(shù)的特化
如果我們希望特化的泛型繼承絕大部分的基泛型的代碼。
那么只需定義特化的成員函數(shù)即可！
在基泛型的定義后面加上特化成員函數(shù)：
template<>
void Manage<B>::sayHello(void){
cout<<"B"<<this->t<<endl;
};
這個特化的函數(shù)就是特化模板類的成員函數(shù)。
實際上，這相當(dāng)于是隱式定義了上面的那樣一個特化模板類，并且所有的基本實現(xiàn)使用基泛型模板的實現(xiàn)！
偏特化/部分特化
就是一個模板類有多個泛型參數(shù)。
我們特化一個模板參數(shù)：
1）基泛型有多個模板參數(shù)：
#pragma once
#include "cppunit/extensions/HelperMacros.h"
#include "B.h"
#include <iostream>
template<typename V,typename T> class Manage
{
private:
T* t;
public:
Manage(void){
this->t=new T();
};
void sayHello(void){
cout<<"管理"<<this->t<<endl;
};
public:
virtual ~Manage(void){};
};
2）定義的特化有一個還是任意的類型參數(shù)
#pragma once
#include "Manage.h"
#include "B.h"
#include <iostream>
/*相當(dāng)于
template<typename V,沒有> class Manage<V,B>
沒有對應(yīng)已有的類型B
*/
template<typename V> class Manage<V,B>
{
private:
B* t;
public:
Manage(void){
this->t=new B();
}
virtual ~Manage(void){};
public:
void sayHello(void){
std::cout<<"B類"<<this->t<<std::endl;
};
};
但是，請注意，半特化，則沒有特化中對應(yīng)的成員函數(shù)的特化那種簡單扼要的形式?。?！
模板的使用使用模板的類應(yīng)該寫在頭文件中，并以源碼的方式發(fā)布C++的泛型編程中，需要把所有使用到泛型聲明或者定義的代碼都直接寫在.h頭文件中，不能寫在.cpp文件中，否則會有很多奇怪的錯誤！
VC2005也還沒有支持分離編譯的export關(guān)鍵字！
模板類只能寫在一個.h文件中。而且，不可以放在dll項目中。因為模板類是無法導(dǎo)出的！
導(dǎo)出以后的模板類，只能夠在外部聲明這個模板類，不能夠?qū)嶋H創(chuàng)建模板類的對象！否則會報告
TestMain.obj : error LNK2019: 無法解析的外部符號"__declspec(dllimport) public: __thiscall net_sf_interfacecpp_core_lang::ObjectRefManage<class AClass>::ObjectRefManage<class AClass>(void)" (
__imp_??0?$ObjectRefManage@VAClass@@@net_sf_interfacecpp_core_lang@@QAE@XZ)，該符號在函數(shù)_main 中被引用
這樣的錯誤。
因為，模板類實際上并沒能編譯成二進(jìn)制代碼。它只是一個宏！需要在編譯時根據(jù)客戶代碼的使用情況生成源代碼，然后再變成二進(jìn)制代碼。
因此，作為宏，它應(yīng)該在.h文件中。作為源代碼的元數(shù)據(jù)，應(yīng)該共享給用戶。因為它需要根據(jù)客戶的使用情況來生成源代碼。因此，它必須在最終客戶代碼一起！
要使用模板類，就必須把它單獨拿出來，把.h這個頭文件/源代碼交給用戶。
用戶在項目中直接作為源代碼使用這個頭文件，才能夠使用這個模板類！
//確保只被引入系統(tǒng)一次
#ifndef _net_sf_interfacecpp_core_lang_ObjectRefManage_h_
#pragma once
#include "..\net_sf_interfacecpp\IObject.h"
//下面是自定義的所有.cpp文件都需要引入的頭文件
//#include "ConfigApp.h"
#include "..\net_sf_interfacecpp\Object.h"
#pragma comment(lib,"..\\debug\\net_sf_interfacecpp.lib")
/*
用于管理任意類的實例的生命周期，使之符合ＩＯｂｊｅｃｔ接口
模板類必須定義在頭文件中
NET_SF_INTERFACECPP_API
*/
namespace net_sf_interfacecpp_core_lang{
template<typename T>
class ObjectRefManage:public IObject
{
private:
IObject* pIObject;
T* pT;
//copy構(gòu)造函數(shù)
ObjectRefManage(const ObjectRefManage &that);
//重載等于操作符
ObjectRefManage& operator=(const ObjectRefManage &that);
//void operator delete(ObjectRefManage* thisPtr);
public:
T* getObjectPtrAndAddRef(){
this->addRef();
return this->pT;
};
T* getObjectPtrNotAddRef(){
return this->pT;
};
ObjectRefManage(void){
//現(xiàn)在引用是
this->pIObject=new Object();
this->pT=new T();
};
long addRef(){
return this->pIObject->addRef();
};
long release(){
long result=this->pIObject->release();
if(result==0){
delete this->pT;
delete this;
return 0;
}
};
void setSingleton(){
this->pIObject->setSingleton();
};
public:
virtual ~ObjectRefManage(void){};
};
}
//確保只被引入系統(tǒng)一次
#define _net_sf_interfacecpp_core_lang_ObjectRefManage_h_
#endif
dll依賴模板時使用方式
1）模板依賴于我們的dll
2）如果我們的類需要使用這個模板，就需要另外建一個dll—ext.dll，包括這個模板，從而間接包括核心dll。
Dll內(nèi)部時可以使用模板的，因為可以直接在生成dll時根據(jù)內(nèi)部的使用模板的情況，創(chuàng)建源代碼，編譯成dll。
但是，如果把dll內(nèi)部的模板發(fā)布出去，這就不行了！
3)這個模板頭文件和dll必須同時提供，避免找不到模板依賴的dll而出錯！
對模板參數(shù)沒有限制是一大誤區(qū)
考察STL和boost中使用泛型的例子。我發(fā)現(xiàn)一個問題。使用模板的類，在使用時，程序員可以指定任何類和基本類型。
但是，實際上，很多模板類在代碼的內(nèi)部實現(xiàn)中，對參數(shù)類型能夠提供的操作實際上是有要求的。如，需要>,<,=等操作是有意義的。
或者需要能夠調(diào)用某個方法。
但是，STL和boost的庫中，均沒有對參數(shù)進(jìn)行限制！
這樣，如果客戶程序員使用了錯誤的參數(shù)類型，那么程序還是能夠正常編譯。只有在運行到這段代碼時，才會報錯。
甚至，由于STL和boost喜歡使用操作符重載，因此，即使運行時，也不會出錯，只是真正的邏輯錯了。這樣的問題，怎么才能找到錯誤點呢？我不禁倒吸了一口涼氣！
翻開C++之父BS的《C++語言的設(shè)計與演化》一書，BS本人對模板的這一描述，令我乍舌！
BS居然認(rèn)為不需要限制模板的參數(shù)類型。認(rèn)為對模板參數(shù)的限制是OOP程序員的偏見！
暈！C++是靜態(tài)編譯型語言，不是ruby，python,JavaScript這樣的動態(tài)面向?qū)ο笳Z言。
如果ruby開發(fā)中，你用了錯誤類型的對象，執(zhí)行時沒有報錯，直到你運行到這段代碼才報錯，那我也沒什么話好說的。人家是解釋型語言，放棄了編譯檢查錯誤，但換來了語言的巨大動態(tài)靈活性。有所得必有所失嘛！這我就不說它了！
但BS認(rèn)為C++不應(yīng)該限制模板的參數(shù)類型，聽任錯誤在運行時爆發(fā)，就讓我無法理解了！
BS，不能因為你對模板的偏愛，讓這么多C++程序陷入危險??！
通過派生對模板的參數(shù)類型加以限制的一種方法。
形如：
Template <typename T> class Compare{};
Template <typename T: Compare > class Vector{};
BS認(rèn)為不應(yīng)該采用這種方式。
在java中使用模板時，我們經(jīng)常使用這種方式。
如：
Public MyClass<E extends String>{……}
但，BS認(rèn)為這種方式不好。而且我在VS2005中也無法編譯這樣的代碼。
確實，這樣會讓模板類的數(shù)量直線上升。
第二種BS提到的方法非常丑陋。
就是讓每一個方法的實現(xiàn)都轉(zhuǎn)換成我們需要的類型。這樣編譯時就會報錯。
第三種方法，就是使用模板的特化，或者叫做專門化。
這是BS推薦使用的方法。我也認(rèn)為應(yīng)該使用模板特化來限制模板的參數(shù)類型。
盡管BS提出這種語法的本意并不是用來限制模板的參數(shù)類型。
因為，BS根本就不認(rèn)為應(yīng)該限制模板的參數(shù)類型。偏執(zhí)的家伙！
使用模板特化限制模板的參數(shù)類型
作為一個堅定的OO程序員，我是不會容許在自己的C++程序中像STL和boost那樣，允許任意參數(shù)類型隨意使用我的模板類的！
BS的觀點，我不能茍同！
我認(rèn)為，可以使用模板特化限制模板的參數(shù)類型。這種辦法是最簡單有效的。
首先，我們定義一個基范型。
然后再在基范型模板類的外部定義幾個重載的方法。
指定如果是我們需要的參數(shù)類型，應(yīng)該執(zhí)行這些方法。
也可以獨立定義特化的模板類。但是，我們上面已經(jīng)說過了，特化模板類，不如特化模板類的成員函數(shù)合算！
最后，我們在基范型的實現(xiàn)中，拋出一個自定義的異常。這樣，如果使用了錯誤的類型，就會拋出異常，導(dǎo)致系統(tǒng)停止運行。我們的客戶就可以發(fā)現(xiàn)問題所在。
當(dāng)然，編譯時，即使是不正確的類型，還是能夠編譯通過。只有在運行時才會把錯誤抓出來。
編譯時檢查不出錯誤，這只能怪BS和C++標(biāo)準(zhǔn)委員會沒有為我們提供限制模板的參數(shù)類型的語法了。
補充：C++的模板和java的模板的異同
Java5中，也引入的泛型語法。如：
Public MyClass<E extends String>{
看上去類似，但是實際實現(xiàn)卻非常不同。
C++的模板，是會在編譯時，先生成很多新的C++類。因此，C++中使用模板有一個問題，就是模板生成的源代碼可能太多。引起編譯的性能問題。
而java的模板實現(xiàn)機(jī)制完全不同。Java模板類在編譯時，會“擦除”類型信息。
不會生成新的java類的源代碼。
因為，java的類繼承體系是單根的，所有類都是Object類的子類。因此，在Java5之前，沒有引入模板這個語法之前，java和它的集合實現(xiàn)類也過得很滋潤。
Java模板類在編譯時，我猜想是這樣子的：
1，首先，擦除模板類型的信息，還是使用原來的Object類型。
2，在所有使用模板的參數(shù)類型的地方，加上強制類型轉(zhuǎn)換，轉(zhuǎn)換成程序員指定的模板參數(shù)類型。
我特別記得BS的一句話，認(rèn)為特有道理：
他在C++中特別把不應(yīng)該使用的語法設(shè)計得丑陋，讓你不想去使用。如：
dynamic_cast < type-id > ( expression )
動態(tài)類型轉(zhuǎn)換。
BS認(rèn)為，顯式的類型轉(zhuǎn)換通常是不必要的。應(yīng)該避免。
我深深地贊同這句話。Java引入模板，應(yīng)該就是為了這個原因。現(xiàn)在，寫Java代碼可以少用很多強制類型轉(zhuǎn)換！
用錯模板的參數(shù)類型，Java編譯器都會準(zhǔn)確地報告錯誤。
唉,C++的模板要是也這樣就好了！
