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