If I do a massive "Find/replace" on "As Integer" and replace it with "As Long" - does this have any potential to cause problems?

Ughh...... Not sure I would replace all.

I know I couldn't, because I've written too damn much meta code....

Do you make any API calls?

oh shit

yeah

Glad I asked first. bwahaha

Yeah. I would make sure to test changes to the Win API. They might need integers still.

Let me know though... I should probably update my SO answer if so.

I was thinking about this though, if VBA automatically converts behind the scenes Integer to Long - does it do this on declaration? or instantiate?

It's all about how it gets stored @enderland. It happens very close to the metal.

Hmmm. So if an API call expects a 16bit integer, how does that actually work I wonder

@RubberDuck oh funny, I just realized that question was from yesterday

I'm pretty sure it's not even talking about in memory

I think it's just referring to the fact that registers are 32 bits

I use CopyMem for a bunch of things and I've never run into a case where I needed to treat an Integer as 4 bytes

Is there a way to check how much memory space it actually takes up @Blackhawk?

yes :P

I literally just posted an answer doing so

I would be very curious what that returns on different versions of Office

Well, you can check the Lenb()

Or you could create a Type

Public Type Test

a As Integer

b As Integer

End Type

and just check the VarPtr()s

c As Integer

@Blackhawk won't that check the string length? not the variable length?

Create some local variables in a function and use the VarPtr to read the memory "around" an integer to see if the other integers are right up next to it

Len = String length

LenB = byte length

you can use LenB on any variable type

including Types

Like this?

Private Sub test()
    Dim i As Integer: i = 10
    Dim l As Long: l = 10

    Debug.Print "i : " & LenB(i)
    Debug.Print "l : " & LenB(l)

End Sub

Should work

ye

2 bytes is 16 bits...

yes

So VBA still stores Integers as 16-bits (unlike modern sane languages :P)

My guess is that the article is referring to how, to get a 16-bit value into a 32-bit register, some masking has to be performed

Except they actually use the word "Type"

or some such

which is hugely misleading if that's the case

@RubberDuck hehe I just added something similar into my answer there

Pretty sure Integers are not auto converted..

displays 2

Where's Spolsky when you need him.....

@Blackhawk do you mind if I include this in my answer there?

@enderland Go for it!

Public Sub Test()
    Dim a As Integer
    Dim b As Integer
    Debug.Print VarPtr(b) - VarPtr(a)
End Sub

Here's a fun one

turns out, function local variables are stored in reverse order

(pushed onto the stack in reverse order?)

@Blackhawk Interesting nugget. =)

thanks @Blackhawk, all the examples are in the answer i have there stackoverflow.com/a/26760080/1048539

@Blackhawk how do you figure?

that prints consecutive memory addresses:

Yes, it does, because you're printing them in reverse order

If VBA stored them in the same order as you declared them, j would have a smaller address than i

Oh wait... the stack grows downward

wait, I just realized I declared them backwards

heh

enderland fails

It looks like: 1. The stack grows downward (successive things pushed on the stack get smaller memory addresses) 2. VBA pushes local variables onto the stack in the order you declare them 3. Therefore, the first local variable has the largest address and the last the smallest

Private Declare Sub CopyMemory Lib "Kernel32.dll" Alias "RtlMoveMemory" (ByVal Destination As Long, ByVal Source As Long, ByVal Length As Integer)

Public Sub Test()
    Dim a As Integer
    Dim b As Integer
    Dim c As Integer

    a = 1
    b = 2
    c = 3

    Dim arr(0 To 5) As Byte

    CopyMemory VarPtr(arr(0)), VarPtr(b) - 2, 6&
End Sub

There's the last one I can think of

loading b and the 2 bytes before and after it shows that the three Integers are right next to each other, two bytes each

(inspecting arr in the watch window)