System.Numerics 是一个单独的程序集的原因[关闭]答案

【问题标题】：The reason of System.Numerics being a separate Assembly [closed]System.Numerics 是一个单独的程序集的原因[关闭]
【发布时间】：2014-02-18 17:14:29
【问题描述】：

System.Numerics 程序集只包含BigInteger 和Complex 两种类型（结构），built in Numerical types 的其余部分包括（int、long、double ...）都在System.dll 程序集中。

为什么要这样分离？例如，我可以在两个程序集中的两种类型的声明中看到，例如：

双：

public struct Double : IComparable, IFormattable, IConvertible, IComparable<double>, IEquatable<double>

复杂：

public struct Complex : IEquatable<Complex>, IFormattable

这里Complex类型实现的接口都是Double用到的，一般都是来自System组件，所以基本上实现的接口不会是分离的原因。

我仍然想知道这种分离背后的目的是什么，它们都是数字类型，它们都是内置的，它们都以某种方式从同一个程序集实现相同的接口，为什么要这样分离，为什么 BigInteger 和复杂类型与所有其他内置数字类型一起在系统程序集中？！

这种分离还伴随着这样一个事实，即 System.Numerics 类型在书籍和教程中确实很少提及，这使得像我这样的年轻初学者开发人员长时间忽视这些类型的存在。

编辑：我这个问题不是说我的观点，我只是不明白这个案例，我问这个问题是为了对平台有更多的了解。

【问题讨论】：

您可能会在不知道它们的情况下走得更久——它们没有被广泛使用。
旁注：通常此类历史问题不会得到有效答案，因为您需要 .Net 设计团队的成员来回答。如果有兴趣，您可以尝试在 blogs.msdn.com 上挖掘笔记...就我个人而言，我认为这些类型需要在运行时的公共部分中没有充分的理由，因为它们针对的是非常具体的一组问题（通常与数学相关）。
不幸的是，总会有一些你从未听说过的东西。就在今天，我了解到KeyedCollection，我们内部有一个实现，我现在要重新访问。

标签： c# .net types .net-assembly numeric

【解决方案1】：

它们被添加到框架中的时间比其他类型晚得多。

所以在某个时候，微软的一些团队正在创建这两种类型，他们必须做出决定：我们是否将它们添加到现有的 DLL 中，例如mscorlib.dll 或 System.dll，还是我们将它们放入一个新的 DLL 中。

我确信他们考虑了所有的优点和缺点。

以下是支持将它们放入单独程序集中的一些可能的论据：

很少需要它们。为什么要使用很少需要的类型来增加现有程序集的大小？
其他人可能已经实现了称为BigInteger 和Complex 的类型。通过不将我们的实现添加到现有程序集中，我们不太可能为他们制造问题（即破坏他们的构建）。
通过将它们放入一个单独的程序集中，我们可以有一个单独的发布周期。我们不必等待 .NET Framework 的下一个版本来发布此程序集。

我知道所有这些论点都有反驳的事实，但他们确实决定创建一个单独的程序集。至于真正的原因，你得问问有问题的团队。话虽如此，许多团队每次想要添加类型时都会问自己同样的问题。以上几点通常在考虑的论点列表中。

【讨论】：

TL;DR; “因为他们选择了”。
@AdamHouldsworth 显然是因为他们选择这样做。但我假设 OP 想知道为什么要做出这个选择。
不要太认真 :-)，我投了赞成票，因为我相信你的观点是有效的。我也投了赞成票，因为这些问题往往只会引发猜想和猜测，除非我们有幸让最初的团队成员过来。
@AdamHouldsworth 非常有效的积分。

【解决方案2】：

除了在基类库之后大量引入之外，它们还表示 CPU 无法运行的数据类型。 BCL 中的运算符可以直接在您的 CPU 上执行，例如加法、减法等。一个值得注意的例外是 decimal 类型，BCL 对此有特殊考虑。

在我看来，第二个重要原因是，将这些类型分开会阻碍它们在所有平台上的使用。在决定在手机或平板电脑上使用BigInteger 之前，您需要特别了解它。

【讨论】：