为什么使用整数而不是长整数? [英] Why Use Integer Instead of Long?

问题描述

我经常看到与 Overflow 错误相关的问题，vba.

我的问题是为什么使用 integer 变量声明而不是仅仅将所有数值变量(不包括 double 等)定义为 long?

除非您正在执行类似 for 循环的操作，您可以保证该值不会超过 32,767 的限制，否则是否会影响性能或其他要求不使用 long?

解决方案

整数变量存储为 16 位(2 字节)数字

Office VBA 参考

<块引用>

长(长整数)变量存储为有符号的 32 位(4 字节)数字

Office VBA 参考

因此，好处是减少了内存空间.Integer 占用的内存是 Long 的一半.现在，我们谈论的是 2 个字节，因此它不会对单个整数产生真正的影响，这只是在处理 TONS 整数(例如大型数组)并且内存使用至关重要时才需要考虑的问题.

但是在32位系统上，内存使用量减半是以性能为代价的.当处理器实际使用 16 位整数执行某些计算时(例如，增加循环计数器)，该值会悄悄地转换为临时 Long，而无法使用更大范围的数字.溢出仍然发生，处理器用来存储计算值的寄存器将占用相同数量的内存(32 位).性能甚至可能受到伤害 因为必须转换数据类型(在非常低的级别).

不是我要找的参考资料而是....

<块引用>

我的理解是，底层的 VB 引擎会将整数转换为 long，即使它被声明为整数.因此可以注意到轻微的速度下降.我已经相信了一段时间，也许这也是为什么做出上述陈述的原因，我没有要求推理.

ozgrid 论坛

这是我要找的参考资料.

<块引用>

简短回答，在 32 位系统中，2 字节整数转换为 4 字节多头.真的没有其他方法可以使相应的位正确排列适合任何形式的处理.考虑以下

MsgBox Hex(-1) = Hex(65535) ' = True

显然 -1 不等于 65535 但计算机返回正确回答，即"FFFF" = "FFFF"

但是，如果我们先将 -1 强制为长，我们就会得到正确的答案(大于 32k 的 65535 自动长)

MsgBox Hex(-1&) = Hex(65535) ' = False

"FFFFFFFF" = "FFFF"

通常在现代 VBA 中没有必要声明作为整数"系统，除了一些希望收到整数.

pcreview 论坛

最后我找到了 msdn 文档我真的很想找.

<块引用>

传统上，VBA 程序员使用整数来保持小数字，因为它们需要更少的内存.在最近的版本中，但是，VBA 将所有整数值转换为 Long 类型，即使它们是声明为整数类型.所以不再有性能优势使用整数变量；其实Long变量可能会略更快，因为 VBA 不必转换它们.

_{根据评论澄清:整数仍然需要更少的内存来存储 - 与具有相同维度的 Long 数组相比，大型整数数组需要的 RAM 少得多.但是因为处理器需要使用 32 位内存块，所以 VBA 在执行计算时会临时将整数转换为长整数}

<小时>

所以，总而言之，现在几乎没有充分的理由使用 Integer 类型.除非您需要与需要 16 位 int 的旧 API 调用互操作，或者您正在处理小整数的大型数组并且内存非常宝贵.><块引用>

值得指出的一件事是，一些旧的 API 函数可能需要 16 位(2 字节)整数的参数，如果您使用的是 32 位并试图传递一个整数(即已经是 4-byte long) 通过引用，由于字节长度不同，它将不起作用.

感谢 Vba4All 指出这一点.

I often see questions relating to Overflow errors with vba.

My question is why use the integer variable declaration instead of just defining all numerical variables (excluding double etc.) as long?

Unless you're performing an operation like in a for loop where you can guarantee that the value won't exceed the 32,767 limit, is there an impact on performance or something else that would dictate not using long?

解决方案

Integer variables are stored as 16-bit (2-byte) numbers

Office VBA Reference

Long (long integer) variables are stored as signed 32-bit (4-byte) numbers

Office VBA Reference

So, the benefit is in reduced memory space. An Integer takes up half the memory that a Long does. Now, we are talking about 2 bytes, so it's not going to make a real difference for individual integers, it's only a concern when you are dealing with TONS of integers (e.g large arrays) and memory usage is critical.

BUT on a 32 bit system, the halved memory usage comes at a performance cost. When the processor actually performs some computation with a 16 bit integer (e.g. incrementing a loop counter), the value silently gets converted to a temporary Long without the benefit of the larger range of numbers to work with. Overflows still happen, and the register that the processor uses to store the values for the calculation will take the same amount of memory (32 bits) either way. Performance may even be hurt because the datatype has to be converted (at a very low level).

Not the reference I was looking for but....

My understanding is that the underlying VB engine converts integers to long even if its declared as an integer. Therefore a slight speed decrease can be noted. I have believed this for some time and perhaps thats also why the above statement was made, I didnt ask for reasoning.

ozgrid forums

This is the reference I was looking for.

Short answer, in 32-bit systems 2 byte integers are converted to 4 byte Longs. There really is no other way so that respective bits correctly line up for any form of processing. Consider the following

MsgBox Hex(-1) = Hex(65535) ' = True

Obviously -1 does not equal 65535 yet the computer is returning the correct answer, namely "FFFF" = "FFFF"

However had we coerced the -1 to a long first we would have got the right answer (the 65535 being greater than 32k is automatically a long)

MsgBox Hex(-1&) = Hex(65535) ' = False

"FFFFFFFF" = "FFFF"

Generally there is no point in VBA to declare "As Integer" in modern systems, except perhaps for some legacy API's that expect to receive an Integer.

pcreview forum

And at long last I found the msdn documentation I was really truly looking for.

Traditionally, VBA programmers have used integers to hold small numbers, because they required less memory. In recent versions, however, VBA converts all integer values to type Long, even if they're declared as type Integer. So there's no longer a performance advantage to using Integer variables; in fact, Long variables may be slightly faster because VBA does not have to convert them.

_{To clarify based on the comments: Integers still require less memory to store - a large array of integers will need significantly less RAM than an Long array with the same dimensions. But because the processor needs to work with 32 bit chunks of memory, VBA converts Integers to Longs temporarily when it performs calculations}

---

So, in summary, there's almost no good reason to use an Integer type these days. Unless you need to Interop with an old API call that expects a 16 bit int, or you are working with large arrays of small integers and memory is at a premium.

One thing worth pointing out is that some old API functions may be expecting parameters that are 16-bit (2-byte) Integers and if you are on a 32 bit and trying to pass an Integer (that is already a 4-byte long) by reference it will not work due to difference in length of bytes.

Thanks to Vba4All for pointing that out.

这篇关于为什么使用整数而不是长整数?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！