C++/CLR泛型与C++模板之间的对比

error C2676: binary ''=='' : ''elemType'' does not define this operator
or a conversion to a type acceptable to the predefined operator

同样，发生的情况是，每个类型参数开始的时候都被Object的四个公共的方法包围着：ToString、GetType、GetHashCode和Equals。其效果是，这种在单独的类型参数上列出约束条件的工作表现了对初始的强硬约束条件的逐步放松。换句话说，作为泛型的作者，你的任务是按照泛型约束列表的约定，采用可以验证的方式来扩展那些允许的操作。我们来看看如何实现这样的事务。

　　 我们用约束子句来引用约束列表，使用非保留字"where"实现。它被放置在参数列表和类型声明之间。实际的约束包含一个或多个接口类型和/或一个类类型的名称。这些约束显示了参数类型希望实现的或者衍生出类型参数的基类。每种类型的公共操作集合都被添加到可用的操作中，供类型参数使用。因此，为了让你的elemType参数调用CompareTo，你必须添加与Icomparable接口关联的约束子句，如下所示：

generic <class elemType>
where elemType : IComparable
public ref class Container
{
　 // 类的主体没有改变 ...
};

这个约束子句扩展了允许elemType实例调用的操作集合，它是隐含的Object约束和显式的Icomparable约束的公共操作的结合体。该泛型定义现在可以编译和使用了。当你指定一个实际的类型参数的时候（如下面的代码所示），编译器将验证实际的类型参数是否与将要绑定的类型参数的约束相匹配：

编译器会提示某些违反了规则的信息，例如sbc的定义。但是泛型的实际的绑定和构造已经由运行时完成了。

　　接着，它会同时验证泛型在定义点（编译器处理你的实现的时候）和构造点（编译器根据相关的约束条件检查类型参数的时候）是否违反了约束。无论在那个点失败都会出现编译时错误。

generic <class T1, class T2, class T3>
where T1 : IComparable, ICloneable, Image
where T2 : IComparable, ICloneable, Image
where T3 : ISerializable, CompositeImage
public ref class Compositor
{
　 // ...
};

在上面的例子中，出现了三个约束子句，同时指定了接口类型和一个类类型（在每个列表的末尾）。这些约束是有额外的意义的，即类型参数必须符合所有列出的约束，而不是符合它的某个子集。我的同事Jon Wray指出，由于你是作为泛型的作者来扩展操作集合的，因此如果放松了约束条件，那么该泛型的用户在选择类型参数的时候就得增加更多的约束。

　　T1、T2和T3子句可以按照其它的次序放置。但是，不允许跨越两个或多个子句指定某个类型参数的约束列表。例如，下面的代码就会出现违反语法错误：

generic <class T1, class T2, class T3>
// 错误的：同一个参数不允许有两个条目
where T1 : IComparable, ICloneable
where T1 : Image
public ref class Compositor
{
　 // ...
};

类约束类型必须是未密封的（unsealed）参考类（数值类和密封类都是不允许的，因为它们不允许继承）。有四个System名字空间类是禁止出现在约束子句中的，它们分别是：System::Array、Syste

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!