4

阅读所有可能的 C# 数组初始化语法我想知道为什么 C# 总是推断出一个较小数据类型的数组，int/Int32例如byteorshort就足够了。

new[] { 30, 130, 230 } // sbyte[] suffices but becomes int[]
new[] { -1, 125, -119 } // sbyte[] suffices  but becomes int[]
new[] { -31647, -1337, 23456} // short suffices but becomes int[]

在引用的问题中，Eric Lippert 指出使用了“最佳类型” - 见下文，但int最佳类型如何？如果我们要矫枉过正，为什么不使用long呢？

数组元素的类型是通过计算所有具有类型的给定元素中的最佳类型（如果有的话）来推断的。所有元素都必须隐式转换为该类型。

我怀疑处理 8 位或 16 位数据类型可能比 32 位结构更快，例如在使用 SIMD 时，其中四个byte实例可以容纳在一个的寄存器空间中int/Int32。我知道JIT 编译器没有（广泛）使用 SSE 指令，但是这种“int无处不在”的用法确保当 JIT 编译器将包含此类优化时它不会有太大帮助。

有人可以详细说明这些事实并说明为什么它总是诉诸于int吗？

// 编辑 // 我并不真正关心规定没有前缀的文字应该被视为int. 重新表述这个问题：

为什么使用大于所需的数据类型？为什么规范对文字有这个规则？ 什么是优势，因为巨大的缺点是远离未来（SIMD）优化。

4

5 回答 5

6

为什么使用大于所需的数据类型？

您以整数进行计算并且可以保证结果适合字节或短字节的业务线应用程序的数量非常少。整数计算结果适合 int 的业务线应用程序的数量是巨大的。

为什么规范对文字有这个规则？

因为这是一个完全明智的规则。它是一致的、清晰的和可以理解的。它在许多语言目标之间做出了很好的折衷，例如合理的性能、与现有非托管代码的互操作性、其他语言用户的熟悉程度以及将数字视为数字而不是位模式。绝大多数 C# 程序都使用数字作为数字。

什么是优势，因为巨大的缺点是远离未来（SIMD）优化。

我向您保证，千分之一的 C# 程序员不会将“难以利用 SIMD 优化”列为 C# 数组类型推断语义的“巨大缺点”。事实上，你可能是唯一的一个。我当然不会想到。如果您是那种非常关心它的人，那么请在数组初始化程序中显示类型。

C# 的设计初衷并不是为了从未来可能发明的机器中榨取最后一盎司的性能，尤其是在涉及类型推断时也不是这样设计的。它旨在提高业务线开发人员的生产力，而业务线开发人员不认为是一个字节columnWidths = new [] { 10, 20, 30 };数组。

于 2014-02-28T18:17:18.837 回答
4

C# 5.0 规范 2.4.4.2

• 如果文字没有后缀，则它具有可以表示其值的第一种类型：int、uint、long、ulong。

• 如果文字以 U 或 u 为后缀，则它具有可以表示其值的第一种类型：uint、ulong。

• 如果文字以L 或l 为后缀，则它具有可以表示其值的第一种类型：long、ulong。

• 如果文字以 UL、Ul、uL、ul、LU、Lu、lU 或 lu 为后缀，则它是 ulong 类型。

你所有的例子都在该列表中排名第一int......

所有整型文字都遵循此规则。这就是为什么var i = 10;也被推断出来的原因int。

于 2014-02-28T13:32:02.307 回答
1

您作为示例使用的文字都有System.Int32，而这些值可以System.Int16在语法上说的窄整数类型（例如 ）中存储而不会丢失System.Int32。

由于每个数组的所有指定成员都是System.Int32，数组具有类型System.Int32[]。

当然，可以定义一种语言，其中整数文字（没有其他指示，如后缀）具有“足以容纳该值的最小整数类型”类型，该语言不是 C#。

在最新的 - V5.0 - C# 语言规范（来自我的 VS2013 安装）中，在第 2.4.4.2 节中：

整数字面量用于写入int、uint、long和类型的值ulong。

IE。没有演员表就无法写出byte, sbyte, short, 或unsigned short文字。

于 2014-02-28T13:33:51.107 回答
1

当您输入没有任何后缀的整数值时，例如30, 130, 230声明int32值；所以

new[] { 30, 130, 230 }; // <- array of int's

如果你想要字节数组，你必须明确地把它：

  new byte[] { 30, 130, 230 }; // <- treat each value as byte
于 2014-02-28T13:33:53.100 回答
-2

我相信操作在本机位大小下运行总是会更快，因此int对于 32 位机器，因此约定。

这也意味着对于运行 64 位应用程序，int64 比 int 更适合用于数组。

于 2014-02-28T13:33:36.680 回答