转换为 int16、int32、int64 - 您如何知道选择哪一个?

发布于 2024-07-09 04:47:45 字数 113 浏览 8 评论 0原文

我经常必须转换检索到的值(通常作为字符串),然后将其转换为 int。 但在 C# (.Net) 中,您必须选择 int16、int32 或 int64 - 当您不知道检索到的数字有多大时,您如何知道选择哪一个?

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?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(6

阳光下慵懒的猫 2024-07-16 04:47:45

这里每个提到声明 Int16 保存 ram 的人都应该投反对票。

您问题的答案是使用关键字“int”(或者如果您愿意,请使用“Int32”)。

这为您提供了高达 24 亿个数字的范围...此外,32 位处理器将更好地处理这些整数...而且(最重要的原因)是,如果您计划使用该 int几乎出于任何原因......它可能需要是一个“int”(Int32)。

在 .Net 框架中,99.999% 的数字字段(整数)都是“整数”(Int32)。

示例:Array.Length、Process.ID、Windows.Width、Button.Height 等 100 万次。

编辑:我意识到我的脾气会让我投反对票……但这是正确的答案。

Everyone here who has mentioned that declaring an Int16 saves ram should get a downvote.

The answer to your question is to use the keyword "int" (or if you feel like it, use "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).

In the .Net framework, 99.999% of numeric fields (that are whole numbers) are "ints" (Int32).

Example: Array.Length, Process.ID, Windows.Width, Button.Height, etc, etc, etc 1 million times.

EDIT: I realize that my grumpiness is going to get me down-voted... but this is the right answer.

携君以终年 2024-07-16 04:47:45

只是想补充一点...我记得在 .NET 1.1 时代,编译器经过了优化,因此“int”操作实际上比字节或短操作更快。

我相信它今天仍然适用,但我现在正在运行一些测试。


编辑:我有一个惊人的发现:short(s) 的加、减和乘运算实际上返回 int!

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.

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!

怪我鬧 2024-07-16 04:47:45

反复尝试 TryParse() 没有意义,您已经声明了一个字段。 除非将该字段设置为“对象”类型,否则您无法改变主意。 这不是一个好主意。

该字段代表的任何数据都具有物理意义。 它是年龄、大小、计数等。物理量对其范围有现实的限制。 选择可以存储该范围的 int 类型。 不要尝试修复溢出,这将是一个错误。

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.

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.

与之呼应 2024-07-16 04:47:45

与当前最流行的答案相反,较短的整数(如 Int16 和 SByte)通常比较大的整数(如 Int32 和 Int64)占用更少的内存空间。 您可以通过实例化大型 sbyte/short/int/long 数组并使用 perfmon 测量托管堆大小来轻松验证这一点。 确实,许多 CLR 风格在对它们进行算术等操作时会扩大这些整数以进行特定于 CPU 的优化,但当作为对象的一部分存储时,它们仅占用必要的内存。

因此,您绝对应该考虑大小,特别是如果您将使用大型整数列表(或包含整数字段的大型对象列表)。 您还应该考虑诸如 CLS 合规性(不允许公共成员中存在任何无符号整数)之类的事情。

对于像将字符串转换为整数这样的简单情况,我同意 Int32 (C# int) 通常最有意义,并且可能是其他程序员所期望的。

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.

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).

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.

叹倦 2024-07-16 04:47:45

如果我们只是谈论几个数字,那么选择最大的数字不会对您的整体内存使用产生明显的影响,并且会正常工作。 如果您正在谈论大量数字,则需要对它们使用 TryParse() 并找出最小的 int 类型,以节省内存。

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.

甜心 2024-07-16 04:47:45

所有计算机都是有限的。 您需要根据您认为的用户需求来定义上限。

如果您确实没有上限并且想要允许“无限”值,请尝试将 .Net Java 运行时库添加到您的项目中,这将允许您使用 java.math.BigInteger 类 - 它可以对几乎无限的大小进行数学计算整数。

注意:.Net Java 库附带完整的 DevStudio,但我认为它们不附带 Express。

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.

Note: The .Net Java libraries come with full DevStudio, but I don't think they come with Express.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文