在ISO-C++中，这将被辨析为第3个foo()，因为字符串字面常量更接近const char*，而非ISO-C++标准库中的string类型。但是，在C++/CLI中，上面的调用将被辨析为第1个foo()，因为现在字符串字面常量被认为更接近System::String，而非字符指针。要理解其中的缘由，让我们往后退两步，先来看看ISO-C++和C++/CLI如何辨析一个重载函数，然后再来看ISO-C++和C++/CLI如何辨析一个字符串字面常量。
一个重载函数的辨析过程通常包含以下三个步骤：
1．选择候选函数集合。候选函数是指那些从词法范畴来看与所调用函数名相匹配的函数。例如，由于我们上面是在R的一个实例上调用foo()，所以所有名称为foo但却不是R或者其基类的成员的那些函数将不被认为是候选函数。这样看来，我们现在有三个候选函数，即R中三个名称为foo的成员函数。如果这个阶段得到的候选函数集合为空，那么调用将告失败。
2．从候选函数集合中选择可用函数集合。可用函数是指函数声明时的参数个数和它们的类型与调用时所指定的相匹配的那些函数。在我们上面的例子中，三个候选函数都是可用函数。如果这个阶段得到的可用函数集合为空，那么调用也将失败。
3．从可用函数集合中选择最匹配的函数。这个阶段将会对实际传递的参数和可用函数所声明的参数之间的转换进行一个排名。对于只含一个参数的函数来说，这个过程比较简单。但是对于含有多个参数的函数来说，这个过程就变得相对有些复杂。如果没有一个最佳的匹配函数胜出，那么调用将告失败。也就是说各个可用函数的参数类型到实际参数类型之间的转换被认为一样的好，换言之多个调用之间产生了混淆。
那么现在摆在我们面前有两个问题：（1）我们实际传递的参数"Pooh"到底是什么类型？（2）在判定类型转换的优劣时采用的是什么算法？
在ISO-C++中，字符串字面常量"Pooh"的类型为const char[5]——注意，在字符串字面常量后面有一个隐含的截断字符null。在上面的例子中显然不存在这样的精确匹配，因此必须应用某种形式的类型转换。这样，两个ISO-C++候选函数（2）和（3）将进行竞争：
void foo( std::string ); // (2)
void foo( const char* ); // (3) |
那么编译器如何从中判断可用函数呢？C++语言对类型转换按照优先顺序定义有一个层级结构，在这个结构中，如果一种转换优于另一种转换，那么它将被排在前面。在C++/CLI中，我们将CLI类型的行为也集成到了ISO-C++的标准类型转换层级结构中。下面是对集成之后的层级结构的一个描述：
1）精确匹配是最好的。需要注意的是精确匹配并不意味着实际传递的参数类型和函数声明的形式参数类型完全匹配。它们只需要“足够接近”就可以了。我们下面将会看到，“足够接近”对于ISO-C++和C++/CLI中的字符串字面常量有着一些不同的含义。
2）在标准转换中，拓宽转换要优于非拓宽转换。例如，将short拓宽为int要优于将int转换为double。
3）标准转换优于装箱（boxing）转换。例如，将int转换为double优于将int装箱为Object。
4）装箱转换优于用户自定义的隐式转换。
5）用户自定义的隐式转换优于没有任何转换！
6）否则，用户必须使用显式的转型符号来表示期望的转换。
对于上面两个ISO-C++下的候选函数，将字符串字面常量转换为一个std::string属于上面第5条，即隐式调用string的构造器来创建一个临时string对象。而将字符串字面常量转换为一个const char* 属于上面第1条。第1条优于第5条，因此，参数为const char*的那个函数在这场竞争中胜出。
这种归属在第1条“精确匹配”下的trivial conversions实际上在技术的定义上是很严格的。总共有4种这样的trivial conversions可以被归为精确匹配。即使在这4种trivial conversions中，为了规范语言对类型的选择，它们也有一个优先级的排序。
大多数读者和程序员可能对于这样的细节没有多大兴趣，并且通常情况下我们也无须深入到这些细节的地方。但是如果我们要得到一个直观的语言行为、并且确保它们在不同的实现上表现相同，这些规则的存在就很有必要。这是因为作为一门编程语言，它的行为一般要具有某种程度的“类型感知”能力，从而允许程序员忽略这些细节。 下面让我们来对这4种trivial conversions做一简单的了解。其中3种被称为左值转换（lvalue transformation）。左值（lvalue）是一个可寻址的，可被执行写操作的程序实体。第4种为限定性转换（qualification conversion），例如，在一个类型声明上加一个const修饰符就属于这种转换。其中3种左值转换优于限定性转换。
在我们上面的例子中，由本地数组到指针的转换，即由const char [5]到const char *，就是一种左值转换。在大多数情况下，我们甚至不将这看作一种转换。
这种形式的左值转换在C++/CLI中仍然适用，但是在我们将System::String类引入之后，字符串字面常量到const char*的转换就不再是最好的匹配了。实际上，在C++/CLI中，"Pooh"这样的字符串字面常量的类型既是const char[5]（C++/CLI对本地类型系统保留后的结果），同时也是System::String（C++/CLI中的托管类型）。这样，在C++/CLI中，字符串字面常量和System::String类型之间是一个精确的匹配，它优于由字符串字面常量到const char*的trivial conversion。
有些朋友看到这里，可能会不高兴，“为什么要这样做？难道ISO-C++对字符串字面常量的处理不能满足C++/CLI的绑定需要吗？”C++/CLI这样做的理由在于字符串字面常量是我们程序中的一个基本元素，而ISO-C++的行为在很多情况下显得并不直观。实际上，这些规则在我们现在看到的结果之前的一年中被来来回回改了3次之多。
这反映了ISO-C++和C++/CLI在对待各自的类型系统时存在的一个基础性差异。在ISO-C++中，除非是显式存在于一个类库中，否则类型就是独立的。因此，在字符串字面常量和std::string之间并没有隐含的类型关系，虽然它们共享着同一个抽象域（domain）。
但是在C++/CLI中，我们支持统一的类型系统。每一个类型，包括字面常量值，都是一个Object的子类。这也是我们为什么可以在一个字面常量值，或者内建类型的对象上直接调用方法的原因。整数字面常量5的类型为Int32，字符串字面常量"Pooh"的类型为String。认为字符串字面常量更接近C风格的字符串，或者就把它看作C风格的字符串是不合适的。
集成后的类型转换层级结构使得一个正常运行的ISO-C++程序在使用/clr编译器开关重新编译后仍能展现同样的行为，但是使用CLI类型的新的C++/CLI程序在处理字符串字面常量时将会体现新的类型优先排序规则。这段讨论的长度相对于这个主题的重要性而言可能并不合适，但是它却向大家揭示了我们到底在将CLI类型系统和ISO-C++语义框架集成在一起的时候，做了哪些工作，以及如何在必要的时候调整在集成过程中所出现的各个情况的优先级。同时，这也提醒大家在将一个本地类重新构造为一个CLI类的过程中需要注意的一些问题。比如有些情况下我们最好要对那些接受字符串字面常量的成员函数进行新的设计，而不是简单地将一个参数为String的函数添加到这些重载函数集合中了事。
另外需要注意的是，String表示的是Unicode字符集。和ASCII字符集不同，这需要两个字节来表示一个字符。虽然在C++/CLI中字符串字面常量的类型为String，但这并不意味着在C++/CLI中，一个字符串字面常量必然会被解析为双字节的字符流。在本地C++中，我们要在字符串字面常量前加一个L来告诉编译器将其看作一个双字节的字符流。在C++/CLI中，我们仍然需要这么做。
查看本文来源
京公网安备 11010802021500号