C# 转换为 int16、int32、int64 - 你怎么知道选择哪一个？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/270263/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Converting to int16, int32, int64 - how do you know which one to choose?
提问by Vidar
I often have to convert a retreived value (usually as a string) - and then convert it to an int. But in C# (.Net) you have to choose either int16, int32 or int64 - how do you know which one to choose when you don't know how big your retrieved number will be?
我经常需要转换一个检索到的值（通常作为一个字符串）——然后将它转换为一个 int。但是在 C# (.Net) 中，您必须选择 int16、int32 或 int64 - 当您不知道检索到的数字有多大时，您怎么知道选择哪一个？
采纳答案by Timothy Khouri
Everyone here who has mentioned that declaring an Int16 saves ram should get a downvote.
这里提到声明 Int16 可以节省 ram 的每个人都应该投反对票。
The answer to your question is to use the keyword "int" (or if you feel like it, use "Int32").
您的问题的答案是使用关键字“int”（或者，如果您愿意，可以使用“Int32”）。
That gives you a range of up to 2.4 billion numbers... Also, 32bit processors will handle those ints better... also (and THE MOST IMPORTANT REASON) is that if you plan on using that int for almost any reason... it will likely need to be an "int" (Int32).
这为您提供了多达 24 亿个数字的范围……此外，32 位处理器将更好地处理这些整数……此外（以及最重要的原因）是，如果您几乎出于任何原因打算使用该整数……它可能需要是一个“int”（Int32）。
In the .Net framework, 99.999% of numeric fields (that are whole numbers) are "ints" (Int32).
在 .Net 框架中，99.999% 的数字字段（即整数）是“int”（Int32）。
Example: Array.Length, Process.ID, Windows.Width, Button.Height, etc, etc, etc 1 million times.
示例：Array.Length、Process.ID、Windows.Width、Button.Height 等等等等 100 万次。
EDIT: I realize that my grumpiness is going to get me down-voted... but this is the right answer.
编辑：我意识到我的脾气暴躁会让我被否决……但这是正确的答案。
回答by TravisO
If we're just talking about a couple numbers, choosing the largest won't make a noticeable difference in your overall ram usage and will just work. If you are talking about lots of numbers, you'll need to use TryParse() on them and figure out the smallest int type, to save ram.
如果我们只是谈论几个数字，选择最大的不会对您的整体 ram 使用产生显着差异，并且只会起作用。如果您正在谈论大量数字，则需要对它们使用 TryParse() 并找出最小的 int 类型，以节省 ram。
回答by Jeff B
All computers are finite. You need to define an upper limit based on what you think your users requirements will be.
所有的计算机都是有限的。您需要根据您认为用户的需求来定义上限。
If you really have no upper limit and want to allow 'unlimited' values, try adding the .Net Java runtime libraries to your project, which will allow you to use the java.math.BigInteger class - which does math on nearly-unlimited size integer.
如果您确实没有上限并希望允许“无限”值，请尝试将 .Net Java 运行时库添加到您的项目中，这将允许您使用 java.math.BigInteger 类 - 它对几乎无限的大小进行数学运算整数。
Note: The .Net Java libraries come with full DevStudio, but I don't think they come with Express.
注意：.Net Java 库带有完整的 DevStudio，但我不认为它们带有 Express。
回答by chakrit
Just wanted to add that... I remembered that in the days of .NET 1.1 the compiler was optimized so that 'int' operations are actually faster than byte or short operations.
只是想补充一点...我记得在 .NET 1.1 时代，编译器已经过优化，因此“int”操作实际上比字节或短操作更快。
I believe it still holds today, but I'm running some tests now.
我相信它今天仍然成立，但我现在正在运行一些测试。
EDIT: I have got a surprise discovery: the add, subtract and multiply operations for short(s) actually return int!
编辑：我有一个惊人的发现：short(s) 的加、减和乘运算实际上返回 int！
回答by Hans Passant
Repeatedly trying TryParse() doesn't make sense, you have a field already declared. You can't change your mind unless you make that field of type Object. Not a good idea.
反复尝试 TryParse() 没有意义，您已经声明了一个字段。除非您将该字段设为 Object 类型，否则您无法改变主意。不是个好主意。
Whatever data the field represents has a physical meaning. It's an age, a size, a count, etc. Physical quantities have realistic restraints on their range. Pick the int type that can store that range. Don't try to fix an overflow, it would be a bug.
该字段表示的任何数据都具有物理意义。它是年龄、大小、计数等。物理量对它们的范围有现实的限制。选择可以存储该范围的 int 类型。不要试图修复溢出，这将是一个错误。
回答by C. Dragon 76
Contrary to the current most popular answer, shorter integers (like Int16 and SByte) do often times take up less space in memory than larger integers (like Int32 and Int64). You can easily verify this by instantiating large arrays of sbyte/short/int/long and using perfmon to measure managed heap sizes. It is true that many CLR flavors will widen these integers for CPU-specific optimizations when doing arithmetic on them and such, but when stored as part of an object, they take up only as much memory as is necessary.
与当前最流行的答案相反，较短的整数（如 Int16 和 SByte）通常比较大的整数（如 Int32 和 Int64）占用更少的内存空间。您可以通过实例化大型 sbyte/short/int/long 数组并使用 perfmon 测量托管堆大小来轻松验证这一点。确实，许多 CLR 风格会在对这些整数进行算术等运算时扩展这些整数以用于 CPU 特定的优化，但是当作为对象的一部分存储时，它们只占用必要的内存。
So, you definitely should take size into consideration especially if you'll be working with large list of integers (or with large list of objects containing integer fields). You should also consider things like CLS-compliance (which disallows any unsigned integers in public members).
因此，您绝对应该考虑大小，特别是如果您将使用大型整数列表（或包含整数字段的大型对象列表）。您还应该考虑 CLS 合规性（不允许在公共成员中使用任何无符号整数）之类的东西。
For simple cases like converting a string to an integer, I agree an Int32 (C# int) usually makes the most sense and is likely what other programmers will expect.
对于像将字符串转换为整数这样的简单情况，我同意 Int32 (C# int) 通常最有意义，并且可能是其他程序员所期望的。
