language-agnostic - 为什么默认情况下语言不会引发整数溢出错误？

Question

在多种现代编程语言(包括 C++、Java 和 C#)中，该语言允许 integer overflow在运行时发生而不引发任何类型的错误条件。

例如，考虑这个(人为的)C# 方法，它没有考虑上溢/下溢的可能性。 (为简洁起见，该方法也不处理指定列表为空引用的情况。)

//Returns the sum of the values in the specified list.
private static int sumList(List<int> list)
{
    int sum = 0;
    foreach (int listItem in list)
    {
        sum += listItem;
    }
    return sum;
}

如果调用该方法如下:

List<int> list = new List<int>();
list.Add(2000000000);
list.Add(2000000000);
int sum = sumList(list);

sumList() 中将发生溢出方法(因为C#中的int类型是32位有符号整数，并且列表中的值的总和超过了最大32位有符号整数的值)。 sum 变量的值为 -294967296(不是值 4000000000)；这很可能不是 sumList 方法的(假设的)开发人员的意图。

显然，开发人员可以使用多种技术来避免整数溢出的可能性，例如使用像 Java 的 BigInteger 这样的类型。 ，或 checked 关键字和 /checked C# 中的编译器开关。

但是，我感兴趣的问题是为什么这些语言被设计为默认情况下允许整数溢出首先发生，而不是例如在运行时执行操作时引发异常，这将导致整数溢出。导致溢出。如果开发人员在编写执行可能导致溢出的算术运算的代码时忽略考虑溢出的可能性，这种行为似乎有助于避免出现错误。 (这些语言可能包含诸如“unchecked”关键字之类的内容，该关键字可以指定一个 block ，在该 block 中允许发生整数溢出而不引发异常，在开发人员明确想要该行为的情况下；C# 实际上是 does have this 。 )

答案是否简单地归结为性能 - 语言设计者不希望他们各自的语言默认具有“慢”算术整数运算，运行时需要做额外的工作来检查是否发生溢出，每个适用的算术运算 - 并且这种性能考虑超过了在发生无意溢出的情况下避免“无声”失败的值(value)？

除了性能考虑之外，这种语言设计决策还有其他原因吗？

Answer 1

在 C# 中，这是一个性能问题。具体来说，就是开箱即用的基准测试。

当 C# 刚刚出现时，微软希望许多 C++ 开发人员能够转向它。他们知道许多 C++ 人员认为 C++ 很快，尤其是比在自动内存管理等方面“浪费”时间的语言更快。

潜在的采用者和杂志评论者都可能获得新 C# 的副本，安装它，构建一个在现实世界中没有人会编写的简单应用程序，在一个紧密的循环中运行它，并测量它需要多长时间拿。然后他们会根据该结果为公司做出决定或发表文章。

他们的测试显示 C# 比本地编译的 C++ 慢，这一事实很快就会让人们对 C# 失去兴趣。您的 C# 应用程序将自动捕获溢出/下溢这一事实是他们可能会错过的事情。因此，默认情况下它是关闭的。

我认为很明显，99% 的时间我们都希望/checked 处于开启状态。这是一个不幸的妥协。