在固定大小的lang中，我应该在64位元上使用'long'而不是'int'吗？
在10年甚至5年内，将没有[ Edit2： 服务器或台式机] 32位CPU。
那么，使用int（32bit）而不是long（64bit）有什么优势吗？
并且使用有任何不利之处int吗？
编辑：
-
通过
10 or 5 years我的意思是在绝大多数地方，这些LANGS使用 -
我的意思 是默认 使用哪种类型。这几天，我什至不必考虑是否应该将其
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位整数时，由于对齐效果更好，所以某些事情
会 更快，但由于内存需求增加，有些事情会变得更慢。并且可能涉及各种其他因素，这些因素肯定会影响两个方向的性能。
如果您真的想知道哪种方法在您的特定环境中对您的特定html" target="_blank">应用程序会更好，那么您将需要对其进行概要分析。这不是一个明显优于另一个优势的情况。
就个人而言，我建议int您在不关心整数大小的情况下遵循典型的使用方法，而在处理整数时使用其他类型。
-
问题内容： 在64位VM中，考虑到long在Java中是64位，因此使用 long 而不是 int 在性能方面会做得更好，因此在64位系统中提取和处理64位字可能比提取32位字更快。（我期望有很多NO，但我正在寻找详细的解释）。 编辑 ：我是说“在64位系统中，拉和处理64位字可能比拉32位字要快”，因为我假设在64位系统中，拉32位数据将需要您首先获得64位。位字，然后屏蔽前32位。 问题答案：
-
问题内容： 在64位计算机上，Java中的int大小是32位还是64位？ 问题答案： 32位。这是Java语言的功能之一，整数的大小不会随基础计算机而变化。请参阅规范的相关部分。
-
问题内容： 我有一个名为.side-el的div，我希望该位置为：fixed; 行为，但是一旦我将位置固定后，宽度就会从右边的位置开始交替变化。正确的宽度将是flexbox设置的宽度。我怎样才能实现这个目标？ 问题答案： 这是一种受引导启发的方法： 这给您的伸缩盒空间提供了呼吸，这是伸缩盒的工作。如果弹性方向是列，则可以改用。 之所以起作用，是因为当您为元素提供固定位置并且a 和0或a top和b
-
但我会得到另一个例外 java.lang.UnsatisfiedLinkError：dlopen失败：“/data/app/com.example.user.project/lib/x86/libtracker.so”是64位而不是32位 我可以看到我的库已经成功构建，这是它在构建时显示的跟踪消息 这是我的CMakeLists 这是我的母语-lib.cpp 那么，Android studio无法从
-
问题内容： 在Java中，是否保证int始终为32位，而长为64位，而不管体系结构是32位还是64位？ 问题答案： Java是平台无关的。所以是32位，并且是64位的。
-
如果和在一个平台上的表示形式相同，那么它们是严格相同的吗？根据C标准，这些类型在平台上的行为是否有任何不同？ 这样做总是有效的吗： 我猜同样的问题也适用于short和int，如果它们碰巧是相同的表示。 在讨论如何为没有stdint.h的嵌入式C89编译器定义类似的typedef（即或）以及这是否重要时，出现了这个问题。