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