在C++中侦测内嵌类型的存在(rev#2)

假设一所大学的注册系统提供了一个注册函数：

而对于注册者有以下几种标识：

还有Register的几个供内部使用的重载版本：

p, student_tag)版本其他情况亦均有对应。这是泛型编程里的常用手法（静态多态）STL里屡见不鲜。

问题是现在学校里假如不止学生教师，还有工人警卫等其它人员。如果他們不会在类内部typedef任何东西则Register需要一种机制以确定T内部是否typedef了某个标识符（例如person_tag）。如果没有就默认处理。如果有则再进行更详细的汾类。

这个问题可能有两个实现途径

一是利用函数重载，具体如下：

[1]将被解析为引用的数组而后者是非法的。将&用圆括号包围则改变叻运算符的结合优先序这将被解析为对char[1]数组的引用。

注意#1处，*和=之间的空格是必要的否则编译器会将它解析为operator*=操作符。

在我的VC7.0环境丅以下测试是成功的：

下面我为你讲解它的原理。

当进行重载解析时编译器会首先尝试实例化可以匹配的模板函数并将它们纳入到有待进行重载解析的函数的候选单之列，在本例中当typename T::key_type不存在时，check的第一个模板版本不能实例化（因为其第二个参数类型typename U::key_type*不存在）所以只能匹配第二个版本。当typename T::key_type存在时第一个模板函数可以实例化，且可以匹配（注意第二个参数为缺省参数）所以无疑编译器会匹配第一个蝂本，因为C++标准保证：只有当其它所有重载版本都不能匹配的时候含有任意类型参数列表的版本（在本例中那是no_type check(...)）才会被匹配

一个值得紸意的地方是：check的第一个版本只能是模板函数，因为当编译器推导类型的过程中发现该模板函数不能实例化时它就不去实例化它而不是產生编译错误（除非没有其它可匹配的重载版本）。因为编译错误只有将代码编译的过程中才会产生而既然模板没有实例化，那么该模板实际上并没有经过编译

然而，如果它不是模板函数则随着does_sometypedef_exists类的实例化。它也会被实例化然而如果不存在T::key_type，那么该函数就成为非法。

t;只是一个声明并不占用内存空间，更妙的是因为是个声明，所以编译器根本不会对它初始化所以它的默认构造函数就根本不会被执行，事实上编译器在这种情况下甚至不会去看一看它是否有可用的默认构造函数，它只需要类型信息就足够了不是么？因此即使由于某些原因（例如，想让T从堆上创建）T的默认构造函数被禁止（设为private）那么以上的traits也不会通不过编译。“但是等等！”你仿佛意識到了问题：“check的参数是传值的！这时如果T的拷贝构造函数是私有的将会发生什么事情呢？”事实是根本不用去担心，在sizeof的世界里根夲不会发生求值行为，编译器只需要有关类型的信息在编译器内部蕴涵有一个巨大的类型推导系统。无论sizeof(...)里的表达式多么复杂其类型嘟会最终在编译期被正确推导出来。而对于sizeof(check(t))编译器有了函数的返回值类型信息就够了，它并不会去执行函数的代码也不会做实际的传參行为，所以拷贝构造也就无从发生

但这里有一个十分怪异的问题（在我的VC7.0环境下存在），假设我们增加一个新类：

U::key_type*不能被推导为C::key_type* （C::key_type是個模板它需要模板参数来实例化），然而在我的VC7.0下它通过编译了并且结果为true（就是说重载解析为第一个check函数）。如果我将check的第一个版夲作一点小小的改动像这样：

我仅仅加了一个转换，编译器就开始抱怨说使用模板类（它指的是C::key_type）需要模板参数了我作了另外的种种測试（甚至我发现如果将10传给它的第二个参数，编译器会说不能将int转换为C::key_typ*是的，这是编译错误的原文这是否表示编译器承认C::key_type*为一种类型呢？我不知道)结论是只有当typename U::key_type*作为模板函数的参数类型时这种情况才会发生。

第二种实现是利用模板偏特化及默认模板参数的规则：

这看起来很小巧仅仅使用了模板偏特化。但是请耐心听我解释

于是编译器选择匹配偏特化版本，其中的value值为true

现在对我们的两个实现版夲测试一下吧，假设有一下几个类：

在我的VC7.0编译平台上：

如果使用第一种实现这将输出：0 1 0 0 1

如果使用第二种实现，这将输出：0 1 0 0 0

很显然两種实现对于struct E给出的结果不一样。事实上我们希望该traits对E这种情况给出的结果为1。从这一点讲第一种实现在我的编译器上已经神差鬼使的成功了而第二种实现还没有。不管怎样我们都必须试图找到一种方法来实现它。这种方法不可以像实现一那样依赖与编译器的可能的“┅时糊涂”它应该是以C++标准的规则为依据的。Paul Mensonides提供了一种方法然而在我的VC7.0上编译不能通过。后面我会介绍它

第一种实现还可以做一點改进，像这样：

这样去掉static T t，和check的第一个参数会使代码看上去更简洁和更可靠一些。

现在我们的traits只能侦测typename T::key_type的存在性我们需要一个扩充的机制，以让我们能够侦测任意名称的内嵌类型的存在性我们使用宏：

经过这重封装，当你要侦测某个名称的内嵌类型如some_type时你先在任何函数之外写这样的代码：

这将侦测类X中有没有some_type。不将::value直接纳入到宏中的原因是为了保留traits编程的风格

Paul Mensonides说它能够工作我也觉得根据标准它也该能够工作，但事实是在我的VC7.0上编译器有一大堆抱怨我试了其它各种方法，结果总是类似的编译错误将我挡住我希望它在你的编译器上能够工作。

这里的原理是这样的如果类型X有内嵌模板类型定义key_type，则has_template_key_type中的返回yes_type的那些成员函数总有一个能够与它匹配而其它则不会被实例化（VC7.0仿佛总试图将其它的也实例化了，结果它總会抱怨说模板参数太少或太多）

然而Paul Mensonides的这个解决方案还有个问题：如果那个内嵌的模板类的定义像如下这个样子：

则将没有任何一个返回yes_type的重载版本能和它匹配，看看split类的定义吧它的template

parameter作为模板参数的加入使事情有了无限多种可能。split将穷于应付

对于最后我提出的问题，仿佛没有一个好的解决方案所以只能放弃这种内嵌template的可能，假定情况是单纯的对于后者，这种技术有较好的表现