我应该使用'long'不是'int'在64位上使用固定类型大小的语言(如Java, c#
本文关键字：语言 Java int 不是 long 64位 我应该 类型 | 更新日期: 2023-09-27 18:03:36
在10年，甚至5年内，将不会有[Edit2:服务器或桌面]32位cpu。
那么，使用int(32位)比long(64位)有什么优势吗?
使用int有什么缺点吗?
编辑:
我所说的
10 or 5 years是指在绝大多数使用这些语言的地方我指的是使用哪种类型默认。这几天我甚至不会费心去想我是否应该使用
short作为循环计数器，只是for(int i...。同样的方式long计数器已经赢了寄存器已经是64位了，32位类型已经没有增益了。我认为在8位类型中有一些损失(你必须操作更多的比特，然后你正在使用)
32位仍然是完全有效的数据类型;就像我们还有16位和字节一样。当我们转向32位处理器时，我们并没有抛弃16位或8位数字。32位数字的存储空间是64位整数的一半。如果我正在建模一个数据库，并且我知道这个值不能大于32位整数所能存储的值;出于存储目的，我会使用32位整数。我也会对16位的数字做同样的事情。64位数字也会占用更多的内存空间;尽管考虑到今天的个人笔记本电脑可以配备8gb内存，这没什么大不了的。
int除了它是一个较小的数据类型之外没有任何缺点。这就像在问:"我应该把糖放在哪里?"在糖碗里，还是在筒仓里?"嗯，这完全取决于你吃了多少糖。
处理器架构应该与你使用的数据类型大小没有太大关系。用合适的。当我们有512位处理器时，我们仍然有字节。
编辑:
处理一些注释/编辑…
-
我不确定"将没有32位桌面cpu"。ARM目前是32位;并宣布对64位计算机不感兴趣;现在。这与你描述中的"桌面"不太相符;但我也认为，在5-10年内，我们编写软件的设备类型也将发生巨大变化。平板电脑不容忽视;考虑到微软正式将Windows 8移植到ARM上，人们会希望c#和Java应用程序在ARM上运行。
-
如果你想开始使用
long;去做吧。没有理由不这样做。如果我们只看CPU(忽略存储大小)，并假设我们是在x86-64架构上，那么它没有太大的区别。 -
假设我们坚持使用x86架构;这也是真的。你可能会得到一个稍微大一点的堆栈;
如果您在64位处理器上，并且您已经为64位编译了代码，那么至少在某些时候，long可能更有效，因为它匹配寄存器大小。但这是否真的会对你的程序产生很大的影响还有待商榷。此外，如果您在所有地方都使用long，则通常会使用更多的内存(堆栈和堆上的内存)，这可能会对性能产生负面影响。使用long而不是int时，有太多的变量可以确定程序的性能。它可以更快，也可以更慢，这是有原因的。
如果你不关心整数的大小，典型的做法是只使用int。如果需要64位整数，则使用long。如果你想使用更少的内存，而int远远超过了你的需要，那么你可以使用byte或short。
x86_64 cpu将被设计为能够高效地处理32位程序，因此使用int并不会严重降低性能。当您在64位CPU上使用64位整数时，由于更好的对齐，有些事情将更快，但由于内存需求的增加，其他事情将变慢。而且很可能还涉及到其他各种因素，这些因素肯定会影响表现。
如果您真的想知道在您的特定环境中哪一个对您的特定应用程序更好，您将需要对它进行配置。这并不是一个有明显优势的例子。
就我个人而言，我建议您在不关心整数大小时遵循典型的路线使用int，当您关心整数大小时使用其他类型
抱歉用c++来回答。
如果字体的大小很重要，则使用大号字体:
-
uint8_t -
int32_t -
int64_t等
如果大小无关紧要，则使用表达型:
-
size_t -
ptrdiff_t -
ssize_t等
我知道D有大小类型和size_t。我不确定是Java还是c#