C# NET是否将64位体系结构上的算术从Int32提升到Int64？

我正在读这篇文章，我想知道，如果CLR将字节和Int16转换为算术的Int32，那么在64位模式下运行时，它会将所有字节、Int16和Int32转换为Int64吗

编辑：从以下循环开始：

for (short i = 0; i < 10; i++) {
    // ...
}

for (int i = 0; i < 10; i++) {
    // ...
}

将执行以下循环：

for (short i = 0; i < 10; i++) {
    // ...
}

for (int i = 0; i < 10; i++) {
    // ...
}

---

实际上，CLR什么都不做：C#编译器做。你看，CLR确实支持

Byte

和

Int16

类型，但是它不支持对它们进行算术运算，所以要对

Byte

和

Int16

执行算术运算，它们最初应该转换为支持的最小类型（

Int32

）

这种转换的行为取决于语言。C#团队选择自动将这些类型的所有计算转换为

Int32

，因此您可以看到相应的IL。VB.NET选择保存类型信息，因此在代码中看不到类型转换，但是在这种情况下，IL代码更麻烦：他们必须使用到

Int32

的转换，检查是否发生溢出，然后从

Int32

转换回来

因此，它依赖于语言。C#规范明确规定算术运算与大小无关，因此在每个平台上，您都会看到转换为

Int32

。CLR确实指定Int32类型始终占用4字节的内存空间，但并不限于此：CLR还支持

native int

type，其大小取决于平台。C#不允许这样做，因此您只能在

unsafe

部分中使用此类型

为清晰起见，省略了P.S.有符号/无符号差异

---

P.P.S.<代码> INTPTR <代码>是安全的，但它的实现依赖于平台：IntPtr。大小是32位的4字节，64位的/P>相关的8字节（如果不是重复的）：与许多生成64位代码的本机C和C++编译器相同的策略，int仍然是32位。正如处理器执行核心的速度一样，提升它并不能为您带来更大的范围或更高的速度。CLI最初是针对不支持分数字大小操作的RISC处理器的，在20世纪90年代末仍然很流行。是的，我使用CLR这个术语来表示负责.NET执行的工具组。当然，CLR不负责生成IL。Int32是受支持的小型类型，但当64位标志打开时它是Int64吗？长话短说：C#自动转换为独立于目标平台的受支持的最小类型，因此它总是

Int32

，因为平台独立性是C的关键特性#