在我的 C# 源代码中，我可能已将整数声明为：
int i = 5;
Int32 i = 5;
在当前普及的32位世界中，它们是等效的。然而，随着我们迈向64位世界，我说以下内容将变得相同，这种说法是否正确？
在当前普及的32位世界中，它们是等效的。但是，随着我们进入64位世界，我所说的将变得相同，这种说法是否正确？
int i = 5;
Int64 i = 5;
10个回答
48
不行。C#规范严格定义int为一个32位的别名，即System.Int32。更改这一点将是一个重大的破坏性变化。
- Jon Skeet
2
3此外，即使在x64架构中，据我所知，只有指针和大小（size_t）是64位宽度，而默认整数仍然是32位宽度。 - Asaf R
2在一些语言中，这取决于编译器。例如，在C++中，64位gcc将long定义为64位，而Visual C++将long保留为32位。但C#不是这样的语言，决策是标准化的，不会留给编译器供应商。 - Ben Voigt
18
testInt的sizeof(testInt)会是8吗？
不会，sizeof运算符需要一个类型作为参数，而testInt是一个局部变量。这将永远不会是8，因为它总是会出错。
即使在64位机器上，VS2010编译C#托管整数也只有4个字节。
正确。我注意到C#规范的18.5.8节将sizeof(int)定义为编译时常量4。也就是说，当你使用sizeof(int)时，编译器只是用4替换了它，就好像你在源代码中写的是“4”一样。
有人知道C#中的标准"int"何时会变成64位吗？
从未。C#规范的4.1.4节指出，“int”是“System.Int32”的同义词。
如果您想要一个“指针大小的整数”，那么请使用IntPtr。IntPtr在不同的体系结构上改变其大小。
- Eric Lippert
12
int 在所有平台上都与 Int32 同义。
微软很可能不会在未来更改它，因为这将破坏大量现有的代码，这些代码假定 int 是 32 位。
- BlueRaja - Danny Pflughoeft
6
5赞同！微软认为向后兼容性很重要。语言的一致性是我喜爱C#而不是C++的原因之一。 - P.Brian.Mackey
3我在这里。感谢制造者，我们终于拥有了一个足够大胆地定义其基本数据类型的 C 风格语言。 - Detmar
-1 .... 这将是一种明确的语言更改，这是极其不可能的。正是这种“预定”的大小是C#的优点之一。 - TomTom
4@TomTom：这就是我说的。 - BlueRaja - Danny Pflughoeft
编译器中是否有一个选项可以将代码编译为32位或64位整数？ - Xavier Poinas
@Xavier：我不认为这是一个好主意，因为（1）它会增加编译代码错误的概率。你不能仅仅通过查看源代码知道
int应该有多宽。你还必须指定如何编译代码，这可能意味着（2）你的源代码变得依赖于特定的编译器。（请记住，虽然C#语言是标准化的，但编译器开关和选项通常不是。） - stakx - no longer contributing5
我认为你可能会困惑的是 int 是 Int32 的别名，因此它始终为4个字节，但是 IntPtr 应该匹配CPU架构的字长，所以在32位系统上它将为4个字节，在64位系统上它将为8个字节。
- Brian Gideon
3
以下内容在C#中始终成立:
sbyte：有符号的8位整数，占用1个字节
byte：无符号的8位整数，占用1个字节
short：有符号的16位整数，占用2个字节 ushort：无符号的16位整数，占用2个字节
int：有符号的32位整数，占用4个字节 uint：无符号的32位整数，占用4个字节 long：有符号的64位整数，占用8个字节 ulong：无符号的64位整数，占用8个字节
一个整数的字面值只是一串数字（例如314159），不带任何明确的类型。 C＃将其分配给序列中最先出现的类型（int，uint，long，ulong）中适合它的第一个类型。 这似乎在上面至少有一个响应中略有混淆。 奇怪的是，在一串数字前出现的负号（减号）并不会将选择缩小为（int，long）。字面值始终为正；负号确实是一个运算符。因此，
一些人认为可以安全地预测，C#（和类似语言）永远不会使用“模糊名称”类型来表示大于等于128位的整数。我们将获得对任意大的整数的良好支持，并在处理器支持进行宽度计算时获得对UInt128、UInt256等的超精确支持，但几乎不会使用其中的任何一个。64位地址空间非常大，如果它们变得太小，那只可能是由于ASLR或更高效的MapReduce等某些特殊原因。
sbyte：有符号的8位整数，占用1个字节
byte：无符号的8位整数，占用1个字节
short：有符号的16位整数，占用2个字节 ushort：无符号的16位整数，占用2个字节
int：有符号的32位整数，占用4个字节 uint：无符号的32位整数，占用4个字节 long：有符号的64位整数，占用8个字节 ulong：无符号的64位整数，占用8个字节
一个整数的字面值只是一串数字（例如314159），不带任何明确的类型。 C＃将其分配给序列中最先出现的类型（int，uint，long，ulong）中适合它的第一个类型。 这似乎在上面至少有一个响应中略有混淆。 奇怪的是，在一串数字前出现的负号（减号）并不会将选择缩小为（int，long）。字面值始终为正；负号确实是一个运算符。因此，
-314159 大概就是 完全相同 于 -((int)314159)。除了显然有一个特殊情况可以使 -2147483648 直接成为 int；否则它将会成为 -((uint)2147483648)。我想这样做可能会产生一些不愉快的结果。一些人认为可以安全地预测，C#（和类似语言）永远不会使用“模糊名称”类型来表示大于等于128位的整数。我们将获得对任意大的整数的良好支持，并在处理器支持进行宽度计算时获得对UInt128、UInt256等的超精确支持，但几乎不会使用其中的任何一个。64位地址空间非常大，如果它们变得太小，那只可能是由于ASLR或更高效的MapReduce等某些特殊原因。
- PreventRage
3
无论您使用32位版本还是64位版本的CLR，在C#中，
int始终表示System.Int32，而long始终表示System.Int64。- marxidad
0
是的，正如Jon所说，与'C/C++世界'不同，Java和C#并不依赖于它们运行的系统。它们对于byte/short/int/long和single/double精度浮点数都有严格定义的长度，在每个系统上都是相等的。
- zappan
2
在C/C++世界中，int类型取决于编译器而不是底层硬件。大多数64位C++编译器仍然使用32位的int类型，但指针将会是64位而不是32位。 - Roddy
1在C语言世界中，他们实际上在C99时期就对整个方案失去了信心，决定不再让long变量变得更长，而是添加了long long。在某种程度上，这是承认具有不可预测（在时间尺度上过长）大小的类型是一个问题。 - Will Dean
-1
没有后缀的int可以是32位或64位，这取决于它所代表的值。
如MSDN所定义：
当整数字面量没有后缀时，其类型是以下类型中可以表示其值的第一个类型：int、uint、long、ulong。
这里是地址： https://msdn.microsoft.com/zh-cn/library/5kzh1b5w.aspx
- House.Lee
1
这是不正确的，源代码被误解了。它谈论的是整数字面量，而
int始终为32位长。 - Raimund Krämer网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接
IntPtr是那种结构。 请参阅Size属性的文档，这将为此提供一些解释。 - MasterMastic