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

generic <class T1, class T2>
where T1 : IComparable<T1>
where T2 : IComparable<T2>
public ref class Compositor
{
　 // ...
};

约束是不能继承的。例如，如果我从Compositor继承得到下面的类，Compositor的T1和T2上的Icomparable约束不会应用在 BlackWhite_Compositor类的同名参数上：

generic <class T1, class T2>
public ref class BlackWhite_Compositor : Compositor
{
　 // ...
};

当这些参数与基类一起使用的时候，这就有几分设计方面的便利了。为了保证Compositor的完整性，BlackWhite_Compositor必须把Compositor约束传播给那些传递到Compositor子对象的所有参数。例如，正确的声明如下所示：

generic <class T1, class T2>
where T1 : IComparable<T1>
where T2 : IComparable<T2>
public ref class BlackWhite_Compositor : Compositor
{
　 // ...
};

包装

　　你已经看到了，在C++/CLI下面，你可以选择CLR泛型或C++模板。现在你所拥有的知识已经可以根据特定的需求作出明智的选择了。在两种机制下，超越元素的存储和检索功能的参数化类型都包含了每种类型参数必须支持操作的假设。

　　使用模板的时候，这些假设都是隐含的。这给模板的作者带来了很大的好处，他们对于能够实现什么样的功能有很大的自由度。但是，这对于模板的使用者是不利的，他们经常面对某些可能的类型参数上的没有正式文档记载的约束集合。违反这些约束集合就会导致编译时错误，因此它对于运行时的完整性不是威胁，模板类的使用可以阻止失败出现。这种机制的设计偏好倾向于实现者。

　　使用泛型的时候，这些假设都被明显化了，并与约束子句中列举的基本类型集合相关联。这对泛型的使用者是有利的，并且保证传递给运行时用于类型构造的任何泛型都是正确的。据我看来，它在设计的自由度上有一些约束，并且使某些模板设计习惯稍微难以受到支持。对这些形式约束的违反，无论使在定义点还是在用户指定类型参数的时候，都会导致编译时错误。这种机制的设计偏好倾向于消费者.

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