纯洁的卓玛---与bu3bu4兄商榷

[xuanyun]

bu3bu4兄在其大作《a story of 卓玛》（http://www.csdn.net/Develop/Article/12/12054.shtm）
中展现了无与伦比的技巧，以至于让我昨天从睡梦中吓醒。咦，我为什么要说“吓”呢？实在是里面判断两个类型是否相同的代码巧妙得接近邪恶了，请看：

//下一段代码摘自《a story of 卓玛》
template<int v>
struct Int2Type
{
enum{value=v};
};
template<class T, class U>
class Conversion
{
typedef char Small;
struct Big {char dummy[2];};
static Small Test(U);
static Big Test(...);
static T MakeT();
public:
enum{ exists=(sizeof(Test(MakeT()))==sizeof(Small))};
};
//摘录end

哦哦，看看吧，那个接受任意参数的Test(...)，还有那个用sizeof变的戏法！看见纯洁的卓玛使用这种类似黑魔法的东东，我能不被吓醒吗？

好吧，好吧，还是让可爱的卓玛走正道吧，下面请看仙女版的卓玛！在这个版本中用到的最高级的技术是member function重载...(真的吗，真的吗，各位观众群情激奋）...呃，还有traits和template specialization...(众怒，蓄力中）...以及类型标签。喂喂，各位请息怒，都撤招了吧，江湖如此险恶，卓玛不用黑魔法总得用白魔法吧，否则这么单纯的姑娘遇到坏人你们就忍心？何况这些技术在教主B.S.的宝典《The C++ Programming Language》都有啊！（各位听到教主的名头，都打了个寒颤，慢慢收了招，xuanyun冒着虚汗接着往下讲）

第一件事情，是为Paper和Gold两种垃圾建立类型标签，实际就是两个最简结构类型：（类型标签技术请看教主宝典19.2.3）

struct paper_tag{};
struct gold_tag{};

然后就用template specialization技术建立trash_traits:

template<class T>
struct trash_traits;//不用实现

template<>
struct trash_traits<Paper>{
typedef paper_tag trash_tag;
};

template<>
struct trash_traits<Gold>{
typedef gold_tag trash_tag;
};

虽然上面这个技术可以在教主宝典19.2.2找到原型，不过推荐看myan大虾翻译的《traits:类型的if-else-then机制》，对traits没有比这篇文章更好的入门读物了！（咦，怎么脖子冷飕飕，教主大人不会在旁边吧）

PaperBin、GoldLib和bu3bu4兄的一样，不用改。下面请看采用了member function overload实现的Management:

class Management{
private:
PaperBin _myPaperBin;
GoldLib _myGoldLib;
template<class T>
void _Add(T& t,paper_tag){
_myPaperBin.push_back(t);
cout<<"a paper got!"<<endl;
}
template<class T>
void _Add(T& t,gold_tag){
_myGoldLib.push_back(t);
cout<<"a gold got!"<<endl;
}
public:
template<class T>
void Add(T& t){
_Add(t,trash_traits<T>::trash_tag());
}
};

嗯，类型标签只有编译时刻的用处：制造出两个重载_Add函数的区别。而traits则用于从垃圾的类型自动推导出恰当的类型标签。大家是否觉得这个版本更优雅而不那么面目狰狞呢？而且更重要的是，这个版本的Management::Add()函数的效率比bu3bu4兄的高得多:它能够根据垃圾类型从众多垃圾箱中“一下子”找到正确的垃圾箱，而不用一个一个尝试。想想垃圾种类很多的情况下两种方案在效率上的差别吧！（仙女般的卓玛扛着成千上万个垃圾箱行走江湖...汗）

这个方案的可扩充性也同样出色，同样假设增加玻璃垃圾：
增加3个类：

struct glass_tag{};//Glass的类型标签
class Glass{}；
class GlassBin:public vector<Glass>{};

增加一个template specialization的traits:

template<>
struct trash_traits<Glass>{typedef glass_tag trash_tag;};

修改Management,除了增加一个GlassBin容器外增加一个重载的_Add()函数：

class Management{
...
template<class T>
void _Add(T& t, glass_tag){
_myGlassBin.push_back(t);
cout<<"a glass got!"<<endl;
}
...
};

好了，用户界面没有任何改变，条理性和清晰性并不差，对不对？（其实好心虚的说）

愿卓玛永远纯洁美丽！

最后，为了方便大家拷贝代码，一份完整的代码列在这儿：

#include <iostream>
#include <vector>

using namespace std;

struct paper_tag{};
struct gold_tag{};
struct glass_tag{};

class Paper{};
class Gold{};
class Glass{};

template<class T>
struct trash_traits;
template<>
struct trash_traits<Paper>{
typedef paper_tag trash_tag;
};
template<>
struct trash_traits<Gold>{
typedef gold_tag trash_tag;
};
template<>
struct trash_traits<Glass>{
typedef glass_tag trash_tag;
};

class PaperBin:public vector<Paper>{};
class GoldLib:public vector<Gold>{};
class GlassBin:public vector<Glass>{};

class Management{
private:
PaperBin _myPaperBin;
GoldLib _myGoldLib;
GlassBin _myGlassBin;
template<class T>
void _Add(T& t,paper_tag){
_myPaperBin.push_back(t);
cout<<"a paper got!"<<endl;
}
template<class T>
void _Add(T& t,gold_tag){
_myGoldLib.push_back(t);
cout<<"a gold got!"<<endl;
}
template<class T>
void _Add(T& t,glass_tag){
_myGlassBin.push_back(t);
cout<<"a glass got!"<<endl;
}
public:
template<class T>
void Add(T& t){
_Add(t,trash_traits<T>::trash_tag());
}
};

int main()
{

Management zhuoma;
Paper apaper;
Gold agold;
Glass aglass;
zhuoma.Add(apaper);
zhuoma.Add(agold);
zhuoma.Add(aglass);
return 0;
}

作者声明：
1，若作非盈利用途，以上文字和代码可以自由传播，修改，但必须包含本声明。
2，作者不保证以上文字和代码的正确性，作者不为任何因使用以上文字和代码造成的损害负责。

[peifang]

你这个看似Generic，本质上却仍然是overload啊。不能为了Generic而Generic啊
Add成为了_Add没有太多意义的封装了啊。

[xuanyun]

to:peifang
但是,如果不用Generic,给用户的接口不可能这么简洁吧!
实际上我觉得Generic的作用就是承担自动根据输入类型选择不同的操作(重载函数).

[peifang]

可是在你的例子中完全没有展现出template的价值啊。
你的Add函数看似用了模版，类型无关了，可是实际应用仍然是_Add的重载。
如果是这样和直接对Add重载不是完全一样么？反而多了一道手续。确实是挂着羊头卖狗肉啊
(嘻嘻嘻，开玩笑呢，我不是说你，而是说你的这个程序啊，不要介意)
Generic的作用可并不是承担自动根据输入类型选择不同的操作，而是类型无关性，把分析类型传递给别的类去处理。就以你上面的例子来说，如果非要generic的话，也不应该由类managment来关心paper还是gold之类的类型细节，而应该让managment把类型的判定交给最底层的类去完成（比如你再设计个traits类之类的）。