合的等于操作符搜索效率较高，但是不适合于所有类型；较灵活的成员模板搜索要求传递用于比较的类型。
哪些对象适用这种比较目的？函数对象就是普通的用于这种目的的C++设计模式。例如，下面就是一个比较两个字符串是否相等的函数对象：
class EqualGuy {
public:
bool operator()( String^ s1, String^ s2 )
{
return s1->CompareTo( s2 ) == 0;
}
}; |
代码4中的代码显示了你如何调用这两个版本的搜索成员函数模板和传统的版本。
代码4：两个搜索函数
int main()
{
Container<String^> ^sxc = gcnew Container<String^>;
sxc->add( "Pooh" );
sxc->add( "Piglet" );
// 成员模板搜索 ...
if ( sxc->search( "Pooh", EqualGuy() ) )
Console::WriteLine( "found" );
else Console::WriteLine( "not found" );
// 传统的等于搜索 ...
if ( sxc->search( "Pooh" ) )
Console::WriteLine( "found" );
else Console::WriteLine( "not found" );
} |
一旦有了模板的概念，你就会发现使用模板几乎没有什么事情不是实现。至少感觉是这样的。
泛型约束
与模板不同，泛型定义支持形式约束语法，这些语法用于描述可以合法地绑定的类型参数。在我详细介绍约束功能之前，我们简短地考虑一下为什么泛型选择了提供约束功能，而模板选择了不提供这个功能。我相信，最主要的原因是两种机制的绑定时间之间差异。
模板在编译的过程中绑定，因此无效的类型会让程序停止编译。用户必须立即解决这个问题或者把它重新处理成非模板编程方案。执行程序的完整性不存在风险。
另一方面，泛型在运行时绑定，在这个时候才发现用户指定的类型无效就已经太迟了。因此通用语言结构（CLI）需要一些静态（也就是编译时）机制来确保在运行时只会绑定有效的类型。与泛型相关的约束列表是编译时过滤器，也就是说，如果违反的时候，会阻止程序的建立。
我们来看一个例子。图5显示了用泛型实现的容器类。它的搜索方法假设类型参数衍生自Icomparable，因此它实现了该接口的CompareTo方法的一个实例。请注意，容器的大小是在构造函数中由用户提供的，而不是作为第二个、非类型参数提供的。你应该记得泛型不支持非类型参数的。
代码5：作为泛型实现的容器
generic <class elemType>
public ref class Container
{
array<elemType> ^m_buf;
int next;
int size;
public:
bool search( elemType et )
{
for each ( elemType e in m_buf )
if ( et->CompareTo( e ))
return true;
return false;
}
Container( int sz )
{
m_buf = gcnew array<elemType>(size = sz);
next = 0;
}
// add() 和 get() 是相同的 ...
}; |
该泛型类的实现在编译的时候失败了，遇到了如下所示的致命的编译诊断信息：
error C2039: ''CompareTo'' : is not a member of ''System::Object''
你也许有点糊涂了，这是怎么回事？没有人认为它是System::Object的成员啊。但是，在这种情况下你就错了。在默认情况下，泛型参数执行最严格的可能的约束：它把自己的所有类型约束为Object类型。这个约束条件是对的，因为只允许CLI类型绑定到泛型上，当然，所有的CLI类型都多多少少地衍生自Object。因此在默认情况下，作为泛型的作者，你的操作非常安全，但是可以使用的操作也是有限的。
你可能会想，好吧，我减小灵活性，避免编 |
