任何优雅的方式来使用泛型类型操作？ [英] Any elegant way to operate with generic types?

问题描述

我在哪里，我们必须实现的 N 的维矩阵小的教育项目。根据上下文，这个矩阵已经不是与我们自己的内置 ComplexNumber 结构工作或 System.Double 和非常简单的例子，与整数类型（主要是 System.Int32 ）。

由于的性质应用程序，我们不要求实现快如闪电的性能。

我的第一个想法，因此是实施矩阵和LT; T> ，其中 T 会以某种方式需要被限制的数字的

在做这个明显的问题是，有没有办法现在的语言来约束泛型类型 T 与定义操作。此外，我没有看到一个简单的方法来restrcit T 来合理的类型

我的问题是：

1. 有人请指出我的的优雅的方式的方向，使数学运算与普通类型的没有按T出色的性能太多，以某种方式使这项工作与内建类型（如果可能）。




2. 如果埃里克的不断读这一点，此功能的（定义为运营商限制泛型类型）曾经拿出在未来的C＃设计会议假想的版本，并有它以往任何时候都接近使它成为语言？

我知道它更容易，更好地实施 ComplexMatrix 键入并为每个矩阵创建一个围绕它的包装分型（双，积分等），并支付转换的性能代价我们复杂的类型和任何类型的矩阵元素碰巧之间。这个问题更多的是出于好奇就如何会有人实施了类似的场景。

解决方案

如果埃里克曾经读取此，

如果您想提醒我注意什么，尽量在我的博客联系链接。或者把我的全名中的问题的文本，以便我寻找我自己会找到我。

此功能的（定义为运营商限制泛型类型）曾经拿出在未来的C＃设计会议假想的版本，并有它以往任何时候都接近要使它成为语言？

事实上，这是一个经常被要求的功能。我们已经得到了这样的事情，因为C＃1.0的要求。

此功能将需要从CLR团队的支持，而不仅仅是语言 - 它是排序功能的，我们会想融入我们所有的语言，从而增加成本。

在CLR团队表示有这样的功能感兴趣，但他们也有很多的竞争，他们可以做的功能，以及有限的时间和精力实现这些功能。

有许多方式这样的特征可以实施。例如，我们可以添加在接口指定静态方法的能力：

 接口IAddable< T> 
 {
静态T接线员+（T X，T Y）; 
} 
  

然后

 静态牛逼总和< T>（IEnumerable的< T>序列），其中T：IAddable< T> 
 {$ B $（B T）和=默认（T）; 
的foreach总和=总和+项目（如序列牛逼的项目）; 
收益总和; 
} 
  

的想法是，该接口装置实现此必须接口的类型具有给定的静态方法。然后，我们会想办法让INT自动实施 IAddable< INT> ，等等。

如何做到这一点的有效的在运行时生成的通用代码的世界是一个开放的问题。

我赶紧补充说，这只是一个想法草图。有实现这种功能的许多方面。在静态接口中的想法是一个已经不仅仅是数学更广泛的使用，这是对我们的吸引力。如果我们打算去这个排序功能的巨大代价，这将是很好有一个非常一般，强大的功能而不是一个狭隘地集中于数学。

在另一方面，完美是好的敌人;它可能是最好只专注于数学问题，而不是去一个更昂贵的通用的解决方案。

这是一个正在进行的辩论。这绝对是大家的雷达屏幕上，但我不会马上想到它的任何时间。语言设计者都埋头于通过从异步CTP反馈去工作。

一如往常，Eric的关于假设的暗访未来产品的假想未来的语言特性冥想仅用于娱乐目的。

I am working in a small educational project where we have to implement a n-dimensional matrix. Depending on the context, this matrix has either to work with our own built-in ComplexNumber struct or with System.Double and for very simple examples, with integral types (mainly System.Int32).

Due to the nature of the application, we are not demanded to implement lightning fast performance.

My first idea was therefore to implement a Matrix<T> where T would somehow need to be restricted to "numbers".

The obvious problem in doing this is that there is no way right now in the language to constraint the generic type T with defined operators. Also I do not see an easy way to restrcit T to reasonable types.

My questions are:

1. Can somebody please point me in the direction of an elegant way to make mathematical operations with generic types that doesn't compromise performance too much and to somehow make that work with built in types (if possible).

2. If Eric ever reads this, does this feature (constraining generic types by defined operators) ever come up in hypothetical future versions of C# design meetings and has it ever been close to making it into the language?

I know its easier and better to implement a ComplexMatrix type and create wrappers around it for each matrix "sub-type" (double, integral, etc.) and pay the performance costs of the conversions between our complex type and whichever type the matrix elements happen to be. This question is more out of curiousity on how would someone implement a similar scenario.

解决方案

If Eric ever reads this,

If you want something brought to my attention, try the contact link on my blog. Or put my full name in the text of the question so that me searching for myself will find me.

does this feature (constraining generic types by defined operators) ever come up in hypothetical future versions of C# design meetings and has it ever been close to making it into the language?

Indeed, this is a frequently requested feature. We've been getting requests for this sort of thing since C# 1.0.

The feature would requires support from the CLR team, not just the language -- it is the sort of feature that we would want to integrate into all our languages, which increases the cost.

The CLR team has expressed interest in features like this, but they also have a lot of competing features that they could be doing, and limited time and effort to implement those features.

There are numerous ways such a feature could be implemented. For example, we could add the ability to specify static methods in interfaces:

interface IAddable<T>
{
    static T operator+(T x, T y);
}

and then

static T Sum<T>(IEnumerable<T> seq) where T : IAddable<T>
{
    T sum = default(T);
    foreach(T item in seq) sum = sum + item;
    return sum;
}    

The idea would be that the interface means "a type that implements this interface must have the given static methods". We'd then make int automatically implement IAddable<int>, and so on.

How do do so efficiently in a world with runtime-generated generic code is an open question.

I hasten to add that this is just a sketch of an idea. There are many ways to implement this sort of feature. The "statics in interfaces" idea is one that has broader usage than just mathematics, and that's attractive to us. If we're going to go to the huge expense of this sort of feature, it would be nice to have a really general, powerful feature rather than one narrowly focussed on math.

On the other hand, the perfect is the enemy of the good; it might be better to just concentrate on the math problem and not go for a more expensive general solution.

It's an ongoing debate. It is definitely on everyone's radar screen, but I would not expect it any time soon. The language designers are all heads-down working on going through the feedback from the async CTP.

As always, Eric's musings about hypothetical future language features of hypothetical unannounced future products are for entertainment purposes only.

这篇关于任何优雅的方式来使用泛型类型操作？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！