引言
我想要分享一个新模式，我开发来用于在 C# 中利用运行时编译进行泛型计算。
过去的几年里我已经在编程并且看到许多在 C# 中实现泛型数学的例子，但是没有一个能做得非常地好。在第一部分中我将一步步地解说我看到的一些例子，同时也会说明为什么他们没有向泛函提供好的模式。
我开发了这个模式以作为我的 Seven Framework 框架工程的一部分。假设您感兴趣的话你可以点击：https://github.com/53V3N1X/SevenFramework。
问题概述
首先，根本的问题是在 C# 中处理泛型就像基类一样。除了 System.Object 基类，他们都没有隐式成员。也就是说，相对于标准数值类型（int，double，decimal，等）他们没有算数运算符和隐式转换。EXAMPLE 1 是一种理想情况，但是这段代码在标准 C# 中是不能编译的。
// EXAMPLE 1 ----------------------------------------
namespace ConsoleApplication
{ public class Program
{ public static void Main(string[] args)
{ Sum<int>(new int[] { 1, 2, 3, 4, 5 }); }
public static T Sum<T>(T[] array)
{ T sum = 0; // (1) cannot convert int to generic
for (int i = 0; i < array.Length; i++)
sum += array[i]; // (2) cannot assume addition operator on generic
return sum; }
}
}
确实如此，EXAMPLE 1 不能通过编译因为：
类型”T”不能确保int数值的隐式转换。 类型”T”不能确保一个加法操作。现在我们了解了根本问题后，让我们开始寻找一些方法克服它。
接口化解决方法
C#中的 where 子句是一种强迫泛型满足某种类型的约束。然而，用这种方法就要求有一种不存在于C#中的基本数值类型。C#有这样一种基本数值类型是最接近强制泛型成为数值类型的可能了，但这并不能在数学上帮助我们。EXAMPLE 2 仍然不能够通过编译，但如果我们创造出了我们自己的基本数值类型，这将成为可能。
Hide Copy Code
// EXAMPLE 2 ----------------------------------------
namespace ConsoleApplication {
public class Program
{
public static void Main(string[] args)
{
Sum<int>(new int[] { 1, 2, 3, 4, 5 });
}
public static T Sum<T>(T[] array)
where T : number // (1) there is no base "number" type in C#
{ T sum = 0;
for (int i = 0; i < array.Length; i++)
sum += array[i];
return sum; }
}
}
现在 EXAMPLE 2 还不能编译因为：
在C#中没有基本“数值”类型。如果我们实现了我们自己的基本“数值”类型，就可以让它通过编译。我们所必需做的就是迫使这个数值类型拥有C#基本数值类型一般的算数运算符和隐式转换。逻辑上来讲，这应该是一个接口。
然而，即使我们自己做数值接口，我们仍然有一个重大问题。我们将不能够对 C＃ 中的基本类型做通用数学计算，因为我们不能改变 int，double，decimal 等的源代码来实现我们的接口。所以，我们不仅必须编写自己的基本接口，还需要为C#中的原始类型编写包装器。
在例3中，我们有我们自己的数值接口，“数字”，和原始类型int的包装器，Integer32。
// EXAMPLE 3 ----------------------------------------
namespace ConsoleApplication
{
public class Program
{
public static void Main(string[] args)
{
Sum(new Number[]
{
new Integer32(1), // (1) initialization nightmares...
new Integer32(2),
new Integer32(3),
new Integer32(4),
new Integer32(5)
});
}
public static Number Sum(Number[] array)
{
Number sum = array[0].GetZero(); // (2) instance-based factory methods are terrible design
for (int i = 0; i < array.Length; i++)
sum = sum.Add(array[i]);
return sum;
}
}
public interface Number
{
Number GetZero(); // (2) again... instance based factory methods are awful
Number Add(Number other);
}
public struct Integer32 : Number // (3) C# primitives cannot implement "Number"
{
int _value;
public Integer32(int value)
{
this._value = value;
}
Number Number.GetZero()
{
return new Integer32(0);
} // (4) you will have to re-write these functions for every single type
Number Number.Add(Number other)
{
return new Integer32(_value + ((Integer32)other)._value);
}
}
} // (5) this code is incredibly slow
好的，这样 EXAMPLE 3 就编译了，但是它有点糟，为什么呢：
编程时用接口初始化变量是非常丑陋的。 你不该用工厂方法或构造函数作为一个实例化方法，因为它是一种糟糕的设计并且很容易在程序各处造成空引用异常。 你不能让C#基本类型去实现“Number”接口所以只能使用自定义类型工作。 它不是泛函因为你必须每一步都写一个自定义的实现。 这段代码因封装了基本类型工作极其慢。假设您的泛函库不能使在 C# 中完成泛型数学运算，没有人会对此买单。因此，接下里让我们处理这个问题。如果不能够修改 C# 原始数据类型去实现想要的接口，那么我们就创造另一种类型能够处理那些类型具有的所有数学运算。这就是在 .Net 框架中广泛使用的标准提供者模式。
边注/发泄：就我个人来说，我憎恨提供者模式。但我至今没有发现使用委托有处理不好的例子。当大量创建大量提供者时，他们没有使用委托。
当我们使用提供者模式，本质上仍是做和以前同样的事，但一个提供者类就能处理所有的数学运算。在EXAMPLE 4中检验它：
/EXAMPLE 4 ----------------------------------------
namespace ConsoleApplication
{
public class Program
{
public static void Main(string[] args)
{
Sum<int>(new int[] { 1, 2, 3, 4, 5}, new MathProvider_int());
} // (1) all the methods need access to the provider
public static T
Sum<T>(T[] array, MathProvider<T> mathProvider)
{
T sum = mathProvider.GetZero();
for (int i = 0; i < array.Length; i++)
sum = mathProvider.Add(sum, array[i]);
return sum; }
public interface MathProvider<T>
{
T GetZero(); // (2) you still need instance factory methods
T Add(T left, T right);
}
public class MathProvider_int : MathProvider<int>
{
public MathProvider_int() { }
int MathProvider<int>.GetZero()
{
return 0;
} // (3) you still have to implement each function for every single type
int MathProvider<int>.Add(int left, int right)
{
return left + right;
}
}
} // (4) can be slow depending on implementation (this version is slow)
EXAMPLE 4 通过把所有的泛函性质移动到帮助类中，我们可以使用C#基本类型执行数学运算。然而，这仅仅修复 EXMAPLE 3 中的第一个问题。我们仍旧需要解决以下问题：
所有方法都必须访问 mathProvider 类。虽然您可以编写代码，让其不必在每个函数间传递，这个原则同样适用于其它类似的结构。 你的实例化仍然基于工厂方法。在上面的情况中它是一个来自于int的转换。 在原始代码中你仍然需要为每一个简单的类型中实现泛函性。 这仍然相当慢，除非你为 provider 做一些”聪明的“缓存。provider 的传递和查找加起来真的很多。现在我们已经尝试过在数值类型本身（EXAMPLE 3）和外部 provider（EXAMPLE 4）上使用接口。使用接口我们已经不能做更多了。可以确定的是我们可以运用一些聪明巧妙的存储方法，但最终仍会面临相同的问题：必须在每一步都支持定制的实现。
最后说一句…在 C# 中接口不适合用在高效的泛函计算中。
对象转换
在 C# 中所有事物都可以转换成 System.Object 类型。因此，我只要把每一个事物转换成一个对象之后呢用控制流处理它就可以了。让我们试一试。
// EXAMPLE 5 ----------------------------------------
namespace ConsoleApplication
{
public class Program
{
public static void Main(string[] args)
{
MathProvider<int>.Sum(new int[] { 1, 2, 3, 4, 5});
}
}
public static class MathProvider<T>
{
public static T Sum(T[] array)
{ // (1) still requires a custom implementation for every type
if (typeof(T) == typeof(int))
{
T sum = (T)(object)0; // (2) largescale casting is very glitch prone
for (int i = 0; i < array.Length; i++)
sum = (T)(object)((int)(object)sum + ((int)(object)array[i]));
return sum; } t
hrow new System.Exception("UNSUPPORTED TYPE"); // (3) runtime errors
} } }
// (4) horribly slow...
事实是，这看起来要比接口化方法好。代码很简单并且容易使用。然而，和以前一样我们还是有很多问题：
我们仍要为每一种类型创建一个定制的实现。 同时我们有大量的类型转换可能造成异常而且很慢。 以及对不支持的类型有运行时错误。 性能低下。注：我不知道他们是否仍然在用 F＃ 来做这个，但是当我浏览 F＃ 中一般的标准数学函数时，他们所做的看起来像是最低水平的对象转换。可笑至极！
对象转换是另一个死胡同，但它至少非常简单易用。
代理
代理……真的很棒！
我们不能像使用原始类型那样高效地完成数学运算。如果没有每种继承关系编译器将不能作出判断，并且我们也不能让C#的原始类型继承我们自己的类。
所以，我们把一般类外的一般代码的功能都移除吧。我们需要怎么做呢？代理！只要在一般的类里设置一个代理，并在运行时从外部分配，这些类型就能够被编译器所识别。
然而，我们可以把委托（代理）放到泛型类中，在外部编译委托（代理）之后呢在运行时分配。
// EXAMPLE 5 ----------------------------------------
namespace ConsoleApplication
{
public class Program
{
public static void Main(string[] args)
{ // (1) requires a constructor method to be called prior to use
MathProviderConstructors.Construct();
MathProvider<int>.Sum(new int[] { 1, 2, 3, 4, 5});
} }
public static class MathProviderConstructors
{
public static void Construct()
{
// (2) still requires a custom implementation for every type
MathProvider<int>.Sum = (int[] array) =>
{
int sum = 0;
for (int i = 0; i < array.Length; i++)
sum = sum + array[i];
return sum;
}; } }
public static class MathProvider<T>
{
// (3) still have runtime errors for non-implemented types (null-ref)
public static System.Func<T[], T> Sum;
} }
EXMAPLE 5 是目前最好的泛函例子。它运行很快，适用于任何类型，并且除了要确保静态构造方法必须被调用外很容易使用。但是，它仍有一些瑕疵…(1)构造方法必须被调用，(2)对每一个类型依旧须要自定义一个实现，(3)还会抛出运行时错误。
在这一点上我们必须做出一些妥协。首先，运行时异常时几乎不可避免的。我能想到的唯一方法是制作一个自定义插件加入到 Visual Studio 中那将会抛出额外的编译错误。那为了这篇文章的目的，就必须处理这个运行时异常。然而最大的问题是我们还是要为我们需要支持的每一个给类型写一个函数。一定会有解决这个问题的办法！
代码
这是我目前的一个通用的数学模式的版本：
using Microsoft.CSharp; using System;
using System.CodeDom.Compiler;
using System.Reflection;
namespace RuntimeCodeCompiling {
public static class Program
{
public static Action action;
public static void Main(string[] args)
{
Console.WriteLine("Sum(double): " + Generic_Math<double>.Sum(new double[] { 1, 2, 3, 4, 5 }));
Console.WriteLine("Sum(int): " + Generic_Math<int>.Sum(new int[] { 1, 2, 3, 4, 5 }));
Console.WriteLine("Sum(decimal): " + Generic_Math<decimal>.Sum(new decimal[] { 1, 2, 3, 4, 5 }));
Console.ReadLine();
}
#region Generic Math Library Example
public static class Generic_Math<T>
{
public static Func<T[], T> Sum = (T[] array) =>
{ // This implementation will make this string be stored in memory during runtime,
//so it might be better to read it from a file
string code = "(System.Func<NUMBER[], NUMBER>)((NUMBER[] array) =>
{ NUMBER sum = 0; for (int i = 0; i < array.Length; i++) sum += array[i]; return sum; })";
// This requires that "T" has an implicit converter from int values and a "+" operator
code = code.Replace("NUMBER", typeof(T).ToString());
// This small of an example requires no namspaces or references
Generic_Math<T>.Sum = Generate.Object<Func<T[], T>>(new string[] { }, new string[] { }, code);
return Generic_Math<T>.Sum(array);
};
}
/// <summary>Generates objects at runtime.</summary>
internal static class Generate
{
/// <summary>Generates a generic object at runtime.</summary>
/// <typeparam name="T">The type of the generic object to create.</typeparam>
/// <param name="references">The required assembly references.</param>
/// <param name="name_spaces">The required namespaces.</param>
/// <param name="code">The object to generate.</param>
/// <returns>The generated object.</returns>
internal static T Object<T>(string[] references, string[] name_spaces, string code)
{
string full_code = string.Empty;
if (name_spaces != null)
for (int i = 0; i < name_spaces.Length; i++)
full_code += "using " + name_spaces[i] + ";";
full_code += "namespace Seven.Generated
{";
full_code += "public class Generator
{";
full_code += "public static object Generate()
{ return " + code + "; } } }";
CompilerParameters parameters = new CompilerParameters();
foreach (string reference in references)
parameters.ReferencedAssemblies.Add(reference);
parameters.GenerateInMemory = true;
CompilerResults results = new CSharpCodeProvider().CompileAssemblyFromSource(parameters, full_code);
if (results.Errors.HasErrors)
{
string error = string.Empty;
foreach (CompilerError compiler_error in results.Errors)
error += compiler_error.ErrorText.ToString() + "/n";
throw new Exception(error);
}
MethodInfo generate = results.CompiledAssembly.GetType("Seven.Generated.Generator").GetMethod("Generate");
return (T)generate.Invoke(null, null);
}
}
#endregion
} }
代码工作原理：
如果通用数学代码存储为一个字符串，可以使用 string hacking（又名macros aka string replace），以改变运行时的代码。我们可以写一个函数，之后呢在使用该函数时改变该函数的类型。因此，我们可以认定泛型有必须的数学操作符来实现该函数。
在第一次调用函泛时，它会构建自己和重新自动分配。这样，我们就不必处理一个愚蠢的构造函数，它只须要根据我们所需构造泛函即可。
据我所知，你不能编译使用运行时编译器编译单个对象，我只是编译了一个返回我需要的值类型的方法。可能存在替代方法，尤其是当你使用序列化技术的时候，但是我不是很熟悉学历恶化格式，所以这种方法对我来说可能更容易。
优点：
小缺点：（这些“缺点”可以克服）
1.它可以是恼人的编写通用的数学函数作为一个字符串。 解决办法：我建议在单独的文件编写通用代码并解析。这样的字符串不是永久被保存在内存，你仍然可以编辑它，就像在 Visual Studio 中使用标准的C＃一样。
2.这不是一个跨平台的例子。补丁：它很容易实现跨平台功能。根据他们的网站所述，这像一个包含反射和运行时编译库的 Mono 项目。因此只要动态查找运行时编译器就能让“生成的”功能类跨平台。
3.如果泛型的“typeof(T).ToString()”被嵌入到泛型中，现在的这些代码将会崩溃。补丁：使用某种类型创建一个函数 再创建一个适当的字符串来表示这种类型达到和原始代码一样的目的。
4.我们还是有编译错误。告诉我们有自定义类型”struct Fraction128“忘记重载”+“运算符。同时也会抛出运行时错误。补丁：这个问题可以通过在编译时写一个 VS 插件去检测泛函运算中使用的类型是否包含基本数值操作符而被修复。我只是把这些问题指出来告诉你们它是可修复的，我不会去做这些。到用的时候，不要干蠢事，:P
结论
通过使用运行时编译，您可以将存在数学运算符和值类型转换的假设强制认定为成立，使你能够做一些真正意义生的数学计算。它是快速的，相对于该篇中介绍的其他方法是易于维护的，而且非常强大。
虽然这不是全部…我心中已经有了一些改进的想法。如果您有任何建议，我很愿意虚心聆听。谢谢！
版权
该篇及相关源代码及文件属于 The Code Project Open License (CPOL)