int是64位C＃中的64位整数吗？
在我的C＃源代码中，我可能已将整数声明为：
int i = 5; 要么
Int32 i = 5;
在目前流行的32位世界中，它们是等价的。 但是，当我们进入64位世界时，我是否正确地说以下内容会变得相同？
int i = 5; Int64 i = 5;
不.C＃规范严格定义int是System.Int32的别名，正好是32位。 改变这将是一个重大的突破性变化。
C＃中的int关键字被定义为System.Int32类型的别名，这是（通过名称判断）意味着是32位整数。 符合规范：
CLI规范第8.2.2节（内置值和引用类型）有一个包含以下内容的表：
System.Int32– 有符号的32位整数C＃规范部分8.2.1（预定义类型）有一个类似的表：
int– 32位有符号整数类型
这保证了CLR中的System.Int32和C＃中的int都将始终为32位。
sizeof（testInt）会不会是8？
不，sizeof（testInt）是一个错误。 testInt是一个局部变量。 sizeof运算符需要一个类型作为其参数。 这永远不会是8因为它总是会出错。
VS2010将ac＃托管整数编译为4字节，即使在64位机器上也是如此。
正确。 我注意到C＃规范的第18.5.8节将sizeof(int)定义为编译时常量4.也就是说，当你说sizeof(int) ，编译器只需将其替换为4; 就像你在源代码中说“4”一样。
有没有人知道C＃中标准的“int”是64时后是什么时候？
决不。 C＃规范的4.1.4节规定“int”是“System.Int32”的同义词。
如果你想要的是一个“指针大小的整数”，那么使用IntPtr。 IntPtr在不同的体系结构上更改其大小。
int始终是所有平台上Int32同义词。
微软将来不太可能改变它，因为它会破坏许多假设int为32位的现有代码。
我认为你可能会感到困惑的是int是Int32的别名所以它总是4个字节，但IntPtr假设与CPU架构的字大小匹配，所以在32位系统上它将是4个字节， 64位系统上的8个字节。
根据C＃规范ECMA-334 ，“11.1.4简单类型”部分，保留字int将别名为System.Int32 。 由于这是在规范中，因此不太可能改变。
无论您使用的是32位版本还是64位版本的CLR，在C＃中， int总是意味着System.Int32而long将始终意味着System.Int64 。
以下内容在C＃中始终如此 ：
sbyte签名8位，1个字节
字节无符号8位，1个字节
短符16位，2个字节
ushort无符号16位，2个字节
int签名32位，4个字节
uint无符号32位，4个字节
长签名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之类的一些神秘的原因。
是的，正如乔恩所说，与“C / C ++世界”不同，Java和C＃并不依赖于他们正在运行的系统。 它们严格定义了byte / short / int / long和单/双精度浮点数的长度，在每个系统上都相等。
int without suffix可以是32位或64位，它取决于它所代表的值。
在MSDN中定义：
当整数文字没有后缀时，它的类型是这些类型中的第一个，其值可以表示为：int，uint，long，ulong。
这是地址： https ： //msdn.microsoft.com/en-us/library/5kzh1b5w.aspx