Generic<Programming>：类型和值之间的映射
Andrei Alexandrescu
在C++中，术语“转化”（conversion）描述的是从另外一个类型的值（value）获取一个类型（type）的值的过程。可是有时候你会需要一种不同类型的转化：可能是在你有一个类型时需要获取一个值，或是其它的类似情形。在C++中做这样的转化是不寻常的，因为类型域和值域之间隔有有一堵很严格的界线。可是，在一些特定的场合，你需要跨越这两个边界，本栏就是要讨论该怎么做到这个跨越。
映射整数为类型
一个对许多的generic programming编程风格非常有帮助的暴简单的模板：
template <int v>
struct Int2Type
{
enum { value = v };
};
对传递的每一个不同的常整型值，Int2Type“产生”一个不同的类型。这是因为不同的模板的实体（instantiation）是不同的类型，所以Int2Type<0>不同于Int2Type<1>等其它的类型的。此外，产生类型的值被“存放”在枚举（enum）的成员值里面。
不管在任何时候，只要你需要快速“类型化”（typify）一个整型常数时，你都可以使用Int2Type。比如这个例子，你要设计一个NiftyContainer类模板。
template <typename T>
class NiftyContainer
{
...
};
NiftyContainer存储了指向T的指针。在NiftyContainer的一些成员函数（member functions）中，你需要克隆类型 T的对象，如果T是一个非多态的类型，你可能会这样说：
T* pSomeObj = ...;
T* pNewObj = new T(*pSomeObj);
对于T是多态类型的情形，情况要更为复杂一些，那么我们假定你建立了这样的规则，所有的使用于NiftyContainer 的多态类型必须定义一个Clone虚拟函数（virtual function）。那么你就可以像这样来克隆对象：
T* pNewObj = pSomeObj->Clone();
因为你的容器（container）必须能够接受这两种类型，所以你必须实现两种克隆算法并在编译时刻选择适当的一个。那么不管通过NiftyContainer的布尔（非类型，non-type）模板参数传递的类型是不是多态的，你都要和它交互，而且还要依赖程序员给它传递的是正确的标识。
template <typename T, bool isPolymorphicWithClone>
class NiftyContainer
{
...
};
NiftyContainer<Widget, true> widgetBag;
NiftyContainer<double, false> numberBag;
如果你存储在NiftyContainer里的类型不是多态的，那么你就可以对NiftyContainer的许多成员函数进行优化处理，因为可以借助于常量的对象大小（constant object size）和值语义（value semantics）。在所有的这些成员函数中，你需要选择一个算法，或是另外一个依赖于模板参数isPolymorphic的算法。
乍一看，似乎只用一个if语句就可以了。
template <typename T, bool isPolymorphic>
class NiftyContainer
{
...
void DoSomething(T* pObj)
{
if (isPolymorphic)
{
... polymorphic algorithm ...
}
else
{
... non-polymorphic algorithm ...
}
}
};
问题是编译器是不会让你摆脱这些代码的。例如，如果多态算法使用了pObj->Clone，那么NiftyContainer::DoSomething就不会那些任何一个没有定义Clone成员函数的类型而编译。的确，看起来在编译时刻要执行哪一个if语句分支是很明显的，但是这不关编译器的事，编译器仍然坚持不懈地尽心尽职地编译这两个分支，即使优化器最终会消除这些废弃代码（dead code）。如果你试图调用NiftyContainer<int, false>的DoSomething函数的话，编译器就会停留在pObj->Clone的调用之处，这是怎么回事？
等等，问题还多着呢。如果T是一个多态类型，那么代码将又一次不能通过编译了。如果T将它的copy constructor设为private和protected，禁止外部对其访问——作为一个行为良好的多态类，应该如此。那么，如果非多态的代码分支要做new T(*pObj)，则代码不能编译通过。
如果编译器不为编译废弃代码费神那多好啊，但无望的期望不是解决之道，那么怎样才是一个满意的解决方案呢？
已经证实，有许多的解决办法。Int2Type就提供了一个非常精巧的解决方案。对应于isPolymorphic的值为true和false，Int2Type可以将特定的布尔值isPolymorphic转化为两个不同的类型。那么你就可以通过简单的重载（overloading）来使用Int2Type<isPolymorphic>了，搞定！
“整型类型化”（integral typifying）风格的原型（incarnation）如下所示：
template <typename T, bool isPolymorphic>
class NiftyContainer
{
private:
void DoSomething(T* pObj, Int2Type<true>)
{
... polymorphic algorithm ...
}
void DoSomething(T* pObj, Int2Type<false>)
{
... non-polymorphic algorithm ...
}
public:
void DoSomething(T* pObj)
{
DoSomething(pObj, Int2Type<isPolymorphic>());
}
};
这个代码简单扼要，DoSomething调用重载了的私有成员函数，根据isPolymorphic的值，两个私有重载函数之一被调用，从而完成了分支。这里，类型Int2Type<isPolymorphic>的虚拟临时变量没有被用到，它只是为传递类型信息之用。
不要太快了，天行者！
看到上面的方法，你可能认为还有更为巧妙的解决之道，可以使用比如template specialization这样的技巧。为什么必须用虚拟的临时变量，一定还有更好的方式。但是，令人惊奇的是，在简单性、通用性和效率上，Int2Type是很难打败的。
一个可能的尝试是，根据任意的T及isPolymorphic的两个可能的值，对NiftyContainer::DoSomething作特殊处理。这不就是partial template specialization的拿手戏吗？
template <typename T>
void NiftyContainer<T, true>::DoSomething(T* pObj)
{
... polymorphic algorithm ...
}
template <typename T>
void NiftyContainer<T, false>::DoSomething(T* pObj)
{
... non-polymorphic algorithm ...
}
看上去很美，可是啊呀，不好，它是不合法的。没有这样的对一个类模板的成员函数进行partial specialization的方式，你可以对整个NiftyContainer作partial specialization：
template <typename T>
class NiftyContainer<T, false>
{
... non-polymorphic NiftyContainer ...
};
你也可以对整个DoSomething作specialization：
template <>
void NiftyContainer<int, false>::DoSomething(int* pObj)
{
... non-polymorphic algorithm ...
}
但奇怪的是，在[1]之间，你不能做任何事。
另一个办法可能是引入traits技术[2]，并在NiftyContainer的外部来实现DoSomething（在traits类中），但把DoSomething分开来实现显得有些笨拙了。
第三个办法仍然试图用traits技术，但把实现都放在一起，这就要在NiftyContainer里面把traits定义为私有的内部类。总之，这是可以的，但在你设法实现的时候，你就会认识到基于Int2Type的风格有多好。而且这种风格最好的地方可能就在于：在实际应用中，你可以把这个小小的Int2Type模板放在库中，并把它的预期使用记录在案。
类型到类型的映射
考虑下面这个函数：
template <class T, class U>
T* Create(const U& arg)
{
return new T(arg);
}
Create通过传递一个参数给T的构造函数（constructor）而产生了一个新的对象。
现在假设在你的应用中用这么一个规则：类型Widget的对象是遗留下来的代码，在构造时必须要带两个参数，第二个参数是一个像-1这样的固定值。在所有派生自Widget的类中你不会碰到什么问题。
你要怎么对Create作特殊化处理，才能让它在处理Widget时，不同于所有的其它类型呢？你是不可以对函数作partial specialization的，也就是说，你不能像这样做：
// Illegal code - don't try this at home
template <class U>
Widget* Create<Widget, U>(const U& arg)
{
return new Widget(arg, -1);
}
由于缺乏函数的partial specialization，我们所拥有的唯一工具，还是重载。可以传递一个类型T的虚拟对象，并重载。
// An implementation of Create relying on overloading
template <class T, class U>
T* Create(const U& arg, T)
{
return new T(arg);
}
template <class U>
Widget* Create(const U& arg, Widget)
{
return new Widget(arg, -1);
}
// Use Create()
String* pStr = Create("Hello", String());
Widget* pW = Create(100, Widget());
Create的第二个参数只是为作选择适当的重载函数之用，这也是这种自创风格的一个问题所在：你把时间浪费在建构一个你不使用的强类型的复杂对象上，即使优化器可以帮助你，但如果Widget屏蔽掉default construtor的话，那优化器也爱莫能助了。
The proverbial extra level of indirection can help here, too. (不好意思，这句不知道怎么翻译)一个想法是：传递T*而不是T来作为虚拟的模板参数。在运行时刻，总是可以传递空指针的，这在构造时的代价是相当低廉的。
template <class T, class U>
T* Create(const U& arg, T*)
{
return new T(arg);
}
template <class U>
Widget* Create(const U& arg, Widget*)
{
return new Widget(arg, -1);
}
// Use Create()
String* pStr = Create("Hello", (String*)0);
Widget* pW = Create(100, (Widget*)0);
这种方式对于Create的使用者来说，是最具迷惑性的。为了保持这种解决风格，我们可以使用同Int2Type有一些类似的模板。
template <typename T>
struct Type2Type
{
typedef T OriginalType;
};
现在你可以这样写了：
template <class T, class U>
T* Create(const U& arg, Type2Type<T>)
{
return new T(arg);
}
template <class U>
Widget* Create(const U& arg, Type2Type<Widget>)
{
return new Widget(arg, -1);
}
// Use Create()
String* pStr = Create("Hello", Type2Type<String>());
Widget* pW = Create(100, Type2Type<Widget>());
比起其它的解决方案来说，这当然更加说明问题。当然，你又得在库里面包含Type2Type并将在它预期使用的地方记录在案。
检查可转化性和继承
在实现模板函数和模板类时，经常会碰到这样的问题：给出两个强类型B和D，你怎么检查D是不是派生自B的呢？
在对通用库作进一步的优化时，在编译时刻发现这样的关系是一个关键。在一个通用函数里，如果一个类实现了一个特定的接口，你就可以借助于一个优化的算法，而不必对其作一个dynamic_cast。
检查派生关系借助于一个更为通用的机制，那就是检查可转化性。同时，我们还要解决这样一个更为普遍的问题：要怎样才能检查一个强类型T是否支持自动转化为一个强类型U？
这个问题有一个解决办法，它可借助于sizeof。（你可能会想，sizeof不就是用作memset的参数吗，是吧？）sizeof有相当多的用途，因为你可以将sizeof使用到任何一个表达式（expression）中，在运行时刻，不管有多复杂，不用计较表达式的值是多少，sizeof总会返回表达式的大小（size）。这就意味着sizeof知道重载、模板实体化和转化的规则——每一个参与C++表达式的东东。实际上，sizeof是一个推导表达式类型的功能齐备的工具。最终，sizeof撇开表达式并返回表达式结果的大小[3]。
可转化性检查的想法借助于对重载函数使用sizeof。你可以巧妙地对一个函数提供两个重载：一个接受可以转化为U的类型，另一个则可以接受任何类型。这样你就可以调用以T为参数的重载函数了，这里T是你想要的可以转化为U 的类型。如果传入的参数为U的函数被调用，则T就转化为U；如果“退化”（fallback）函数被调用，则T不转化为U。
为了检查是哪一个函数被调用了，你可以让两个重载函数返回不同大小的类型，并用sizeof对其进行鉴别。只要是不同大小的类型，它们就难逃法眼。
首先创建两个不同大小的类型（显然，char和long double有不同的大小，但标准没有作此担保），一个简单的代码摘要如下所示：
typedef char Small;
struct Big { char dummy[2]; };
由定义可知，sizeof(Small)大小为1，Big的大小是未知的，但肯定是大于1的，对于我们来说，能保证这个已经足够了。
下一步，需要做两个重载，一个接受U并返回一个Small。
Small Test(U);
那你要怎样来写一个可以接受任何“东东”的函数呢？模板解决不了这个问题，因为模板会寻找最匹配的一个，由此而隐藏了转化。我们需要的是一个比自动转化要更差一些的匹配。快速浏览一下应用于给定了省略号的函数调用的转化规则。它就在列表的最后面，就是最差的那个，这恰恰就是我们所需要的。
Big Test(...);
（以一个C++对象来调用一个带省略符的函数会产生未知的结果，可谁在乎呢？又不会有人真的调用这样的函数，这种函数甚至都不会被实现。）
现在我要对Test的调用使用sizeof，给它传递一个T：
const bool convExists =
sizeof(Test(T())) == sizeof(Small);
就是它！Test调用产生了一个缺省构造对象T，然后sizeof提取了表达式的结果的大小。它可能是sizeof（Small），也可能是sizeof（Big），这要看编译器是否找到了转化的可能。
还有一个小问题，如果T把它的缺省构造函数作为私有成员会怎么样？在这种情况下，T的表达式将不能通过编译，我们所构建的所有的这一切都是白费。幸好，这又一个简单的解决方案——只要使用一个能返回T的像稻草人一样没用的函数就好了。这样，一切问题统统解决！
T MakeT();
const bool convExists =
sizeof(Test(MakeT())) == sizeof(Small);
(By the way, isn't it nifty just how much you can do with functions, like MakeT and Test, which not only don't do anything, but which don't even really exist at all?)
（顺便说一下，就像MakeT和Test一样，这类函数是好是坏取决于你用它来做什么，它不但什么都不做，而且甚至根本不存在的？）
现在我们可以让它工作了，把一切都封装到一个类模板中，隐藏所有关于类型推导的细节，只把结果暴露出来。
template <class T, class U>
class Conversion
{
typedef char Small;
struct Big { char dummy[2]; };
static Small Test(U);
static Big Test(...);
T MakeT();
public:
enum { exists =
sizeof(Test(MakeT())) == sizeof(Small) };
};
现在你可以这样来测试Conversion模板类了。
int main()
{
using namespace std;
cout
<< Conversion<double, int>::exists << ' '
<< Conversion<char, char*>::exists << ' '
<< Conversion<size_t, vector<int> >::exists << ' ';
}
这个小程序的打印结果为“1 0 0”。我们注意到，尽管std::vector实现了一个带参数为size_t的构造函数，转化测试返回的结果还是0，因为构造函数是显式的（explicit）。
我们可以在Conversion中实现这样的两个或是更多的常量（constants)。
exists2Way表示在T和U之间是否可以相互转化。例如，int和double就是可以相互转化的情况，但是各种自定义类型也可以实现这样的相互转化。
sameType表示T和U是否是同种类型。
template <class T, class U>
class Conversion
{
... as above ...
enum { exists2Way = exists &&
Conversion<U, T>::exists };
enum { sameType = false };
};
我们通过对Conversion作partial specialization来实现sameType。
template <class T>
class Conversion<T, T>
{
public:
enum { exists = 1, exists2Way = 1, sameType = 1 };
};
那么，怎么来做派生关系的检查呢？最漂亮的地方就在于此，只要你把转化处理好了，派生关系的检查就简单了。
#define SUPERSUBCLASS(B, D) (Conversion<const D*, const B*>::exists && !Conversion<const B*, const void*>::sameType)
是不是一目了然了？可能还有一点点的迷糊。SUPERSUBCLASS(B, D)判断D公有派生自B是否为真，或者B和D代表的是同种类型。通过判别一个const D*到const B*的可转化性，SUPERSUBCLASS就可以作出这样的判断。const D*隐式转化为const B*只有三种情况：
B和D是同种类型；
B是D的明确的公有基类；
B是空类型。
通过第二个测试可以排除最后一种情形。在实际应用中，第一种情形（B和D为同种类型）的测试是很有用的。因为出于实际考虑，你通常都会考虑一个类是它自己的超类。如果你需要一个更严格的测试，可以这样写：
#define SUPERSUBCLASS_STRICT(B, D) (SUPERSUBCLASS(B, D) && !Conversion<const B, const D>::sameType)
为什么这些代码中都加上了const修饰呢？原因是你总不想因为const的问题而让转化测试失败吧。所以，在每个地方都使用了const，如果模板代码使用了两次const（对一个已经是const的类型使用const），则第二个const将被忽略掉。简而言之，在SUPERSUBCLASS中使用const是基于安全考虑的。
Why SUPERSUBCLASS and not the cuter BASE_OF or INHERITS? For a very practical reason: with INHERITS(B, D), I kept forgetting which way the test works — does it test whether B inherits D or vice versa? SUPERSUBCLASS(B, D) makes it clearer (at least for me) which one is first and which one is second.
为什么用SUPERSUBCLASS而不是更为贴切的BASE_OF或是INHERITS呢？为了一个实际的原因：使用INHERITS(B, D)，我会经常忘记检测的运作方式——它测试的是B派生自D呢，还是D派生自B？而对这个问题（谁是第一个谁是第二个），SUPERSUBCLASS(B, D)说明得更为清楚一些（至少对于我来说）。
小结
在这里介绍这三种风格，一个最重要的地方就是它们是可重用的。你可以把它们写在一个库里面，并可以让程序员们使用它们，而不是要他们掌握这其中复杂的内部实现工作。
nontrivial技术的可重用性是很重要的，要人们记住一个复杂的技术，即使这个技术可以用来帮助他们的实际工作更为简化一些，但如果这个技术稍显麻烦，他们也是不会用的。给人们一个简单的黑盒，它可以带来一些有用的惊奇，人们是会喜欢它并使用它的，因为这是一个“自由”的方式。
Int2Type，Type2Type，特别是Conversion都属于一个通用的工具库。通过使用重要的编译时刻的类型推导，它们扩展了程序员的编译时刻的能力。
致谢
如果Clint Eastwood问我：“你感觉幸运吗？”，我的回答肯定为“是”。这是我这个系列的第三篇文章，这得益于 Herb Sutter的直接的关注和重要的建议。感谢日本的Tomio Hoshida发现了一个bug并做了一些有深刻见解的建议。
注：这篇文章引用自Andrei Alexandrescu的即将出版的一本书，书名暂定为《Modern C++ Design》(Addison-Wesley, 2001)。（译注：这本书已经出版了，要是能早日拜读，那有多爽啊）
注释
[1]C++对函数的partial specialization支持是没有概念上的障碍的，这是一个很有价值的特性。
[2] Andrei Alexandrescu. "Traits: The else-if-then of types", C++ Report (April 2000).
[3]建议在C++中加入一个类型of操作符，也就是一个返回一个表达式的类型的操作符。有了这么一个操作符，将会使编写模板代码更加易于编写、易于理解。GNU C++已经把typeof作为一个扩展实现了。明显地，typeof和sizeof有同样的障碍，因为无论如何，sizeof都必须计算类型。[参阅Bill Gibbons在CUJ上的一篇文章，他介绍了一个漂亮的方法，这个方法用于在现在的Standard C++里创造一个（几乎是）天然的typeof操作符。]
