我应该在固定类型大小的langs中使用’long’代替’int’而不是’int’（如Java，C＃）
在10年甚至5年内，将没有[ Edit2：服务器或桌面] 32位CPU。
那么，使用int （32bit）over long （64bit）有什么好处吗？
使用int有什么缺点吗？
编辑：
-
到了
10 or 5 years我的意思是绝大多数使用这些lang的地方 -
我的意思是默认使用哪种类型。 这一天我甚至都懒得去想是否应该使用
short作为周期计数器，只是for(int i...同样long计数器已经赢了 -
寄存器已经是64位，32位类型已经没有增益。 我认为8位类型有一些损失（你必须使用更多的位然后你正在使用）
如果您使用的是64位处理器，并且已经编译了64位代码，那么至少在某些时候， long可能会更高效，因为它与寄存器大小相匹配。 但这是否真的会影响你的计划是有争议的。 此外，如果你在整个地方使用long ，你通常会在堆栈和堆上使用更多内存 – 这可能会对性能产生负面影响。 有太多的变量可以确定程序在默认情况下使用long而不是int 。 有理由说它可能更快，以及为什么它可能会变慢。 这可能是彻底清洗。
典型的做法是如果你不关心整数的大小就使用int 。 如果需要64位整数，则使用long 。 如果你试图使用更少的内存并且int远远超过你的需要，那么你使用byte或short 。
x86_64 CPU将被设计为在处理32位程序时高效，因此使用int不会严重降低性能。 当你在64位CPU上使用64位整数时，由于更好的对齐，有些东西会更快，但是由于内存需求增加，其他东西会变慢。 并且可能存在各种其他因素，这些因素肯定会影响任一方向的表现。
如果您真的想知道在特定环境中哪个特定应用程序会做得更好，那么您将需要对其进行分析。 这不是一个明显优于另一个的情况。
就个人而言，我建议您在不关心整数大小时使用int的典型路径，并在使用其他类型时使用。
32位仍然是完全有效的数据类型; 就像我们还有16位和字节一样。 当我们转向32位处理器时，我们没有丢弃16位或8位数字。 就存储而言，32位数字是64位整数的一半。 如果我在建模数据库，我知道它的值不能高于32位整数可以存储的值; 我会使用32位整数进行存储。 我也用16位数字做同样的事情。 64位数字也会占用更多内存空间; 尽管今天个人笔记本电脑没有任何重要意义，但它可以配备8 GB的内存。
除了较小的数据类型之外，int没有缺点。 这就像问：“我应该把糖储存在哪里？在糖碗里，还是一个筒仓里？” 那么，这完全取决于你有多少糖。
处理器架构不应与您使用的大小数据类型有多大关系。 使用什么适合。 当我们有512位处理器时，我们仍然会有字节。
编辑 ：
解决一些评论/编辑..
-
我不确定“没有32位台式机CPU”。 ARM目前是32位; 并宣称对64位没什么兴趣 ; 目前。 这与你的描述中的“桌面”不太合适; 但我也认为，在5到10年内，我们编写软件的设备类型的格局也将发生巨大变化。 平板电脑不容忽视; 考虑到微软正式将Windows 8移植到ARM，人们会希望在它们上运行C＃和Java应用程序。
-
如果你想开始使用
long; 前进。 没有理由不这样做。 如果我们只关注CPU（忽略存储大小），并假设我们在x86-64架构上，那么它没有太大的区别。 -
假设我们坚持使用x86架构; 这也是真的。 你最终可能会有一个稍大的堆栈; 取决于您使用的任何框架。
对不起C ++的答案。
如果类型的大小重要使用大小类型：
-
uint8_t -
int32_t -
int64_t - 等等
如果大小无关紧要使用表达类型：
-
size_t -
ptrdiff_t -
ssize_t - 等等
我知道D有大小类型和size_t 。 我不确定Java或C＃。