使用 Int32 类型需要对 System 进行名称空间引用,或者完全限定( System.Int32 ) . 我倾向于 int ,因为它不需要命名空间导入,因此在某些情况下减少命名空间冲突的可能性 . 编译为IL时,两者之间没有区别 .
5
根据Visual Studio 2012中的立即窗口Int32是int,Int64很长 . 这是输出:
sizeof(int)
4
sizeof(Int32)
4
sizeof(Int64)
8
Int32
int
base {System.ValueType}: System.ValueType
MaxValue: 2147483647
MinValue: -2147483648
Int64
long
base {System.ValueType}: System.ValueType
MaxValue: 9223372036854775807
MinValue: -9223372036854775808
int
int
base {System.ValueType}: System.ValueType
MaxValue: 2147483647
MinValue: -2147483648
30 回答
您不应该关心大多数编程语言,除非您需要编写非常具体的数学函数或针对特定架构优化的代码...只需确保类型的大小对您来说足够(如果您使用大于Int的东西) know 例如,你需要超过32位)
没关系 . int是语言关键字,Int32是其实际系统类型 .
另见我的answer here相关问题 .
使用Int或Int32是相同的Int只是糖来简化读者的代码 .
使用Nullable变体Int?还是Int32?在包含null的字段上使用数据库时 . 这样可以避免许多运行时问题 .
int是一个C#关键字,是明确的 .
大多数时候它没关系,但有两件事与Int32相反:
您需要"using System;"语句 . 使用"int"不需要使用using语句 .
可以定义自己的类Int32(这将是愚蠢和混乱) . int总是表示int .
如前所述,
int
=Int32
. 为了安全起见,在实现任何关心数据类型边界的内容时,请务必始终使用int.MinValue
/int.MaxValue
. 假设.NET认为int
现在是Int64
,您的代码将更少依赖于边界 .int
和Int32
之间没有区别,但由于int
是一个语言关键字,很多人都喜欢它的风格(就像string
vsString
一样) .int
和Int32
是一样的 .int
是Int32
的别名 .你不应该在乎 . 如果大小是一个问题,我会使用byte,short,int,然后long . 使用大于int32的int的唯一原因是,如果需要高于2147483647或低于-2147483648的数字 .
除了我不在乎之外,还有很多其他项目需要关注 .
int
是System.Int32
的别名,如下表所定义:Built-In Types Table (C# Reference)如果Microsoft将整数的默认实现更改为某个新的版本(我们称之为Int32b),我使用int .
然后,Microsoft可以将int别名更改为Int32b,并且我不必更改任何代码以利用其新的(并且希望改进的)整数实现 .
任何类型关键字也是如此 .
我总是使用系统类型 - 例如,Int32而不是int . 我在阅读Applied .NET Framework Programming之后采用了这种做法 - 作者杰弗里里希特为使用完整的类型名称提供了一个很好的案例 . 以下是与我相关的两点:
类型名称可能因.NET语言而异 . 例如,在C#中,
long
映射到System.Int64,而在C中使用托管扩展,long
映射到Int32 . 由于语言可以在使用.NET时进行混合和匹配,因此无论读者的首选语言如何,您都可以确保使用显式类名称将更加清晰 .许多框架方法都将类型名称作为其方法名称的一部分:
BinaryReader br = new BinaryReader( /* ... */ );
float val = br.ReadSingle(); // OK, but it looks a little odd...
Single val = br.ReadSingle(); // OK, and is easier to read
ECMA-334:2006 C#语言规范(p18):
这两者确实是同义词;
int
会更熟悉一下,Int32
使32位更加明确地读取您的代码 . 我倾向于使用int
我只需要'an integer',Int32
其中大小很重要(加密代码,结构)所以未来的维护者会知道如果合适的话放大int
是安全的,但是应该注意以同样的方式改变Int32
.结果代码将是相同的:差异纯粹是可读性或代码外观之一 .
它们都声明了32位整数,并且正如其他海报所述,你使用哪一个主要是语法风格 . 然而,它们并不总是以相同的方式行事 . 例如,C#编译器不允许这样:
但它会允许这样:
去搞清楚 .
当你只需要处理一种语言时,类型的字节大小就不那么有趣了(对于那些你不必提醒自己有关数学溢出的代码) . 变得有趣的部分是当你在一种语言与另一种语言之间架起桥梁,C#与COM对象等等,或者你正在做一些变换或掩盖,你需要提醒自己(和你的代码审查共同工作者)的数据大小 .
在实践中,我通常使用Int32来提醒自己它们的大小,因为我写了托管C(例如桥接到C#)以及非托管/本机C .
只要你可能知道,在C#中是64位,但在本机C中,它最终为32位,或者char是unicode / 16位,而在C中它是8位 . 但我们怎么知道呢?答案是,因为我们在手册中查了一遍,并且说了这么多 .
有了时间和经验,当你编写代码以便在C#和其他语言之间架起桥梁时,你会开始变得更加认真(这里的一些读者会想“为什么会这样?”),但恕我直言,我相信这是一种更好的做法,因为我不记得上周我编写的内容(或者我不必在我的API文档中指定“此参数是32位整数”) .
在F#(虽然我从未使用过它),它们定义了int,int32和nativeint . 同样的问题应该上升,"which one do I use?" . 正如其他人所提到的,在大多数情况下,它应该无关紧要(应该是透明的) . 但我会选择int32和uint32来消除歧义 .
我想这只取决于你编码的应用程序,谁在使用它,什么您和您的团队遵循的编码实践等,以证明何时使用Int32 .
根据我的经验,这是一个常规的事情 . 我不知道在Int32上使用int的任何技术原因,但它是:
键入更快 .
对典型的C#开发人员更熟悉 .
默认的visual studio语法高亮显示中的不同颜色 .
我特别喜欢最后一个 . :)
在定义变量时我总是使用别名类型(int,string等),并在访问静态方法时使用实名:
看到类似int.TryParse()的东西似乎很难看 . 除了风格之外别无他法 .
我知道最好的做法是使用int,所有MSDN代码都使用int . 但是,据我所知,没有超出标准化和一致性的理由 .
虽然它们(大多数)是相同的(参见下面的[bug]差异),你绝对应该关心并且你应该使用Int32 .
16位整数的名称是Int16 . 对于64位整数,它是Int64,对于32位整数,直观的选择是:int或Int32?
Int16,Int32或Int64类型的变量大小的问题是自引用的,但int类型变量大小的问题是一个完全有效的问题,无论多么微不足道,问题都会分散注意力,导致混乱,浪费时间,阻碍讨论等(这个问题存在的事实证明了这一点) .
使用Int32促使开发人员意识到他们选择的类型 . 再一次int有多大?哦是的,32 . 当名称中包含大小时,实际考虑类型大小的可能性更大 . 使用Int32还可以提升对其他选择的了解 . 当人们不被迫至少认识到有替代品时,int变得太容易变成“整数型” .
框架中用于与32位整数交互的类名为Int32 . 再一次,这是:更直观,更少混淆,缺乏(不必要的)翻译(不是系统中的翻译,但是在开发人员的心目中),等等
int lMax = Int32.MaxValue
或Int32 lMax = Int32.MaxValue
?int不是所有.NET语言中的关键字 .
虽然有争论为什么它不可能改变,但int可能并不总是Int32 .
缺点是要输入两个额外字符和[bug] .
这不会编译
但这会:
你不应该在乎 . 你应该在大多数时候使用
int
. 它将有助于将程序移植到更广泛的架构中(目前int
是System.Int32
的别名,但可能会改变) . 仅当变量的位宽很重要时(例如:控制struct
的内存中的布局),您应该使用int32
和其他(带有关联的“using System;
”) .int是C#语言System.Int32的快捷方式
虽然这确实意味着微软可以改变这种映射,但关于FogCreek讨论的一篇文章表明[source]
“在64位问题上 - 微软确实在研究64位版本的.NET Framework,但我很确定int不会映射到该系统上的64位 .
原因:
C#ECMA标准明确指出int为32位,long为64位 .
Microsoft在Framework 1.1版中引入了其他属性和方法,这些属性和方法返回long值而不是int值,例如Array.GetLongLength以及Array.GetLength .
所以我认为可以肯定地说所有内置的C#类型都会保留当前的映射 . “
int与System.Int32相同,编译时会在CIL中变成相同的东西 .
我们在C#中按惯例使用int,因为C#看起来像C和C(和Java),这就是我们在那里使用的...
顺便说一句,我在声明导入各种Windows API函数时最终使用System.Int32 . 我不确定这是否是一个定义的约定,但它提醒我,我要去外部DLL ...
曾几何时,int数据类型与编译器所针对的机器的寄存器大小挂钩 . 因此,例如,16位系统的编译器将使用16位整数 .
但是,幸运的是,我们还没有看到更多的16位,当64位开始受欢迎时,人们更关心的是使它与旧版软件兼容,并且32位已经存在了这么长时间以至于对于大多数编译器而言假设是32位 .
一世'd recommend using Microsoft' s StyleCop .
它就像FxCop,但与风格相关的问题 . 默认配置与Microsoft的内部样式指南相匹配,但可以为您的项目自定义 .
它可能需要一点时间来习惯,但它肯定会使你的代码更好 .
您可以将其包含在构建过程中以自动检查违规 .
它在实践中没有任何区别,您将采用自己的惯例 . 我倾向于在分配类型时使用关键字,而在使用静态方法时使用类版本等:
int total = Int32.Parse(“1009”);
一些编译器在不同平台上具有不同的int大小(不是C#特定的)
一些编码标准(MISRA C)要求使用的所有类型都是指定的大小(即Int32而不是int) .
为不同的类型变量指定前缀也很好(例如b表示8位字节,w表示16位字,l表示32位长字=> Int32 lMyVariable)
你应该小心,因为它使你的代码更便携,更易于维护 .
如果您总是要使用C#,则Portable可能不适用于C#,并且C#规范在这方面永远不会改变 .
可维护的ihmo将永远适用,因为维护代码的人可能不知道这个特定的C#规范,并且错过了一个错误,因为int偶尔会超过2147483647 .
在一个简单的for循环中,例如一年中的几个月,你不会在意,但是当你在可能有能力的上下文中使用变量时,你应该关心 .
您还应该关心是否要对其进行逐位操作 .
使用
Int32
类型需要对System
进行名称空间引用,或者完全限定(System.Int32
) . 我倾向于int
,因为它不需要命名空间导入,因此在某些情况下减少命名空间冲突的可能性 . 编译为IL时,两者之间没有区别 .根据Visual Studio 2012中的立即窗口Int32是int,Int64很长 . 这是输出:
还要考虑Int16 . 如果你需要在你的应用程序的内存中存储一个Integer并且你担心使用的内存量,那么你可以使用Int16,因为它使用更少的内存并且具有比Int32更小的最小/最大范围(这是int是什么 . )
不久前,当我们访问Microsoft .NET CLR产品团队的某个人时,我正在与Microsoft合作开展一个项目 . 这个人编码的例子,当他定义他的变量时,他使用“Int32”与“int”和“String”与“string” .
我记得在微软的其他示例代码中看到了这种风格 . 所以,我做了一些研究,发现每个人都说除了语法着色之外,“Int32”和“int”之间没有区别 . 事实上,我发现很多材料建议您使用“Int32”来使您的代码更具可读性 . 所以我采用了这种风格 .
前几天我确实发现了一个不同!编译器不允许您使用“Int32”键入枚举,但是当您使用“int”时它会执行 . 不要问我为什么,因为我还不知道 .
例:
这有效 .
摘自:Int32 notation vs. int