it-swarm.cn

我应该使用int还是Int32

在C#中,intInt32是相同的,但我已多次读过int优于Int32而没有给出任何理由。有原因,我应该关心吗?

339
Graham

ECMA-334 :2006 C#语言规范 (p18):

每种预定义类型都是系统提供的类型的简写。例如,关键字int指的是struct System.Int32。作为一种风格问题,使用关键字比使用完整的系统类型名称更受青睐。

126
SpaceghostAli

这两者确实是同义词; int会更熟悉一下,Int32使32位更明确地读取你的代码。我倾向于使用int,我只需要'整数',Int32,其中大小很重要(加密代码,结构),所以未来的维护者会知道如果合适的话放大int是安全的,但是应该注意改变Int32s同样的方式。

结果代码将是相同的:差异纯粹是可读性或代码外观之一。

263
James Sutherland

它们都声明了32位整数,并且正如其他海报所述,你使用哪一个主要是语法风格。然而,它们并不总是以相同的方式行事。例如,C#编译器不允许这样:

public enum MyEnum : Int32
{
    member1 = 0
}

但它会允许这样:

public enum MyEnum : int
{
    member1 = 0
}

去搞清楚。

84
raven

我总是使用系统类型 - 例如,Int32而不是int。我在阅读应用.NET Framework编程后采用了这种做法 - 作者Jeffrey Richter为使用完整类型名称提供了一个很好的案例。以下是与我相关的两点:

  1. 类型名称可能因.NET语言而异。例如,在C#中,long映射到System.Int64,而在带有托管扩展的C++中,long映射到Int32。由于语言可以在使用.NET时进行混合和匹配,因此无论读者的首选语言如何,您都可以确保使用显式类名称将更加清晰。

  2. 许多框架方法都将类型名称作为其方法名称的一部分:

    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

48
Remi Despres-Smyth

int是一个C#关键字,是明确的。

大多数时候它没关系,但有两件事与Int32相反:

  • 你需要一个“使用系统”;声明。使用“int”不需要using语句。
  • 可以定义自己的类Int32(这将是愚蠢和混乱)。 int总是表示int。
20
Brownie

如前所述,int = Int32。为了安全起见,在实现关心数据类型边界的任何内容时,请务必始终使用int.MinValue/int.MaxValue。假设.NET认为int现在是Int64,你的代码将更少依赖于边界。

13
spoulson

当你只需要处理一种语言时,类型的字节大小就不那么有趣了(对于那些你不必提醒自己有关数学溢出的代码)。变得有趣的部分是当你在一种语言与另一种语言之间架起桥梁,C#与COM对象等等,或者你正在做一些变换或掩盖,你需要提醒自己(和你的代码审查共同工作者)的数据大小。

在实践中,我通常使用Int32来提醒自己它们的大小,因为我编写了托管C++(例如桥接到C#)以及非托管/本机C++。

只要您知道,C#是64位,但在本机C++中,它最终为32位,或者char为unicode/16位,而在C++中则为8位。但我们怎么知道呢?答案是,因为我们在手册中查了一遍,并且说了这么多。

有了时间和经验,当你编写代码以便在C#和其他语言之间架起桥梁时,你会开始变得更加认真(这里的一些读者正在思考“你为什么会这样?”),但恕我直言,我认为这是一种更好的做法,因为我不记得上周我编写的内容(或者我不必在我的API文档中指定“此参数是32位整数”)。

F# (虽然我从未使用它),它们定义 int int32 ,和 nativeint 。同样的问题应该出现,“我使用哪一个?”。正如其他人所提到的,在大多数情况下,它应该无关紧要(应该是透明的)。但我会选择int32和uint32来消除歧义。

我想这将取决于您正在编码的应用程序,使用者,您和您的团队遵循的编码实践等,以证明何时使用Int32。

9
HidekiAI

intInt32之间没有区别,但由于int是一个语言关键字,很多人都喜欢它的风格(就像string vs String)。

8
Simon Steele

根据我的经验,这是一个常规的事情。我不知道在Int32上使用int的任何技术原因,但它是:

  1. 键入更快。
  2. 对典型的C#开发人员比较熟悉。
  3. 默认visual studio语法高亮显示中的不同颜色。

我特别喜欢最后一个。 :)

7
Greg D

在定义变量时我总是使用别名类型(int,string等),并在访问静态方法时使用实名:

int x, y;
...
String.Format ("{0}x{1}", x, y);

看到类似int.TryParse()的东西似乎很难看。除了风格之外别无他法。

6
Mark A. Nicolosi

虽然它们(大多数)是相同的(参见下面的[bug]差异),你绝对应该关心并且你应该使用Int32。

  • Int-16的整数名称为Int16。对于64位整数,它是Int64,对于32位整数,直观的选择是:int或Int32?

  • Int16,Int32或Int64类型的变量大小的问题是自引用的,但int类型变量大小的问题是一个完全有效的问题,无论多么微不足道,问题都会分散注意力,导致混淆,浪费时间,阻碍讨论等(这个问题存在的事实证明了这一点)。

  • 使用Int32可以促使开发人员意识到他们选择的类型。再一次int有多大?哦是的,32。当名称中包含大小时,实际考虑类型大小的可能性更大。使用Int32还可以提升对其他选择的了解。当人们不被迫至少认识到有替代品时,int变得太容易变成“整数型”。

  • 用于与32位整数交互的框架中的类名为Int32。再一次,这是:更直观,更少混淆,缺乏(不必要的)翻译(不是系统中的翻译,但是在开发人员的脑海中),等等int lMax = Int32.MaxValueInt32 lMax = Int32.MaxValue

  • int不是所有.NET语言中的关键字。

  • 虽然有争议为什么它不可能永远不会改变,但int可能并不总是Int32。

缺点是要输入两个额外字符和[bug]。

这不会编译

public enum MyEnum : Int32
{
    AEnum = 0
}

但这会:

public enum MyEnum : int
{
    AEnum = 0
}
5
unknown (yahoo)

我知道最好的做法是使用int,所有MSDN代码都使用int。但是,据我所知,没有超出标准化和一致性的理由。

5
Raithlin

你不应该在乎。你应该在大多数时候使用int。它将有助于将程序移植到更广泛的架构中(目前intSystem.Int32的别名,但可能会改变)。只有当变量的位宽很重要时(例如:控制struct的内存布局),你应该使用int32和其他(带有相关的“using System;”)。

4
yhdezalvarez

我建议使用Microsoft的 StyleCop

它就像 FxCop ,但与风格相关的问题。默认配置与Microsoft的内部样式指南相匹配,但可以为您的项目自定义。

它可能需要一点时间来习惯,但它肯定会使你的代码更好。

您可以将其包含在构建过​​程中以自动检查违规。

3
devstuff

int与System.Int32相同,编译时会在 _ cil _ 中变成相同的东西。

我们在C#中按惯例使用int,因为C#看起来像C和C++(和Java),这就是我们在那里使用的...

顺便说一句,我在声明导入各种Windows API函数时最终使用System.Int32。我不确定这是否是一个定义的约定,但它提醒我,我要去外部DLL ...

3
Jack Bolding

曾几何时,int数据类型与编译器所针对的机器的寄存器大小挂钩。因此,例如,16位系统的编译器将使用16位整数。

但是,幸运的是,我们还没有看到更多的16位,当64位开始流行时,人们更关心的是使它与旧软件兼容,32位已经存在了很长时间以至于大多数编译器 int 假设是32位。

3
Joel Coehoorn

int是C#语言System.Int32的快捷方式

虽然这确实意味着微软可以改变这种映射,但关于FogCreek讨论的帖子 [来源]

“在64位问题上 - 微软确实在开发64位版本的.NET Framework,但我很确定int不会映射到该系统上的64位。

理由: /

1. C#ECMA标准明确指出int为32位,long为64位。

2. Microsoft在Framework 1.1版中引入了其他属性和方法,它们返回long值而不是int值,例如Array.GetLongLength以及Array.GetLength。

所以我认为可以说所有内置的C#类型都会保留当前的映射。“

3
Ray Hayes

你不应该在乎。如果大小是一个问题,我会使用byte,short,int,然后long。使用大于int32的int的唯一原因是,如果需要高于2147483647或低于-2147483648的数字。

除了我不在乎之外,还有很多其他项目需要关注。

2
David Basarab

intInt32是一样的。 intInt32的别名。

2
Jesper Kihlberg

它在实践中没有任何区别,并且您将采用自己的惯例。我倾向于在分配类型时使用关键字,而在使用静态方法时使用类版本等:

int total = Int32.Parse(“1009”);

2
chrisb

intSystem.Int32的别名,如下表所定义: 内置类型表(C#参考)

1
Jim T

使用Int或Int32是相同的Int只是糖来简化读者的代码。

使用Nullable变体Int?还是Int32?在包含null的字段上使用数据库时。这样可以避免许多运行时问题。

0
bovium

不久前,当我们访问Microsoft .NET CLR产品团队的某个人时,我正在与Microsoft合作开展一个项目。这个人编码的例子,当他定义他的变量时,他使用“Int32”与“int”和“String”与“string”。

我记得在微软的其他示例代码中看到了这种风格。所以,我做了一些研究,发现每个人都说除了语法着色之外,“Int32”和“int”之间没有区别。事实上,我发现很多材料建议您使用“Int32”来使您的代码更具可读性。所以,我采用了这种风格。

前几天我确实发现了一个不同!编译器不允许您使用“Int32”键入枚举,但是当您使用“int”时它会执行。不要问我为什么,因为我还不知道。

例:

public  enum MyEnum : Int32
{
    AEnum = 0
}

这有效。

public enum MyEnum : int
{
    AEnum = 0
}

取自: Int32表示法与int

0
Schmuli

一些编译器在不同平台上具有不同的int大小(不是C#特定的)

一些编码标准(MISRA C)要求使用的所有类型都是指定的大小(即Int32而不是int)。

为不同类型变量指定前缀也很好(例如,b代表8位字节,w代表16位字,l代表32位长字=> Int32 lMyVariable)

你应该小心,因为它使你的代码更便携,更易于维护。

如果您总是要使用C#,则Portable可能不适用于C#,并且C#规范在这方面永远不会改变。

可维护的ihmo将永远适用,因为维护代码的人可能不知道这个特定的C#规范,并且错过了一个错误,因为int偶尔会超过2147483647。

在一个简单的for循环中,例如一年中的几个月,你不会在意,但是当你在可能有能力的上下文中使用变量时,你应该关心。

您还应该关心是否要对其进行逐位操作。

0
user11211

您不应该关心大多数编程语言,除非您需要编写非常具体的数学函数或针对特定体系结构优化的代码...只需确保类型的大小对您来说足够(如果您使用大于Int的东西) 知道 你需要超过32位的例子)

0
Stacker

使用Int32类型需要对System或完全限定(System.Int32)的命名空间引用。我倾向于int,因为它不需要命名空间导入,因此在某些情况下减少命名空间冲突的可能性。编译为IL时,两者之间没有区别。

0
Michael Meadows

没关系。 int是语言关键字,Int32是其实际系统类型。

另见我的 答案 相关问题。

0
Keith

根据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
0
Selim

还要考虑Int16。如果你需要在你的应用程序的内存中存储一​​个Integer并且你担心使用的内存量,那么你可以使用Int16,因为它使用更少的内存并且具有比Int32更小的最小/最大范围(这是int是什么。)

0
Chris Pietschmann