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节(内置值和引用类型)有一个包含以下内容的表:
C#规范部分8.2.1(预定义类型)有一个类似的表:
这保证了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
上述就是C#学习教程:int是64位C#中的64位整数吗?分享的全部内容,如果对大家有所用处且需要了解更多关于C#学习教程,希望大家多多关注—计算机技术网(www.ctvol.com)!
本文来自网络收集,不代表计算机技术网立场,如涉及侵权请联系管理员删除。
ctvol管理联系方式QQ:251552304
本文章地址:https://www.ctvol.com/cdevelopment/985543.html