A = A(0)

[Dimster]

Is there a difference between Dim A as integer and Dim A(0) as integer??

[SpriggsySpriggs]

There probably is a difference between them. The IDE will probably try to write it as an array with zero elements on the backend. You would probably even be able to resize it later.

[bplus]

a(0) It requires the typing of 3 more keys, seems foolish to me.

[SMcNeill]

DIM A AS INTEGER
DIM A(0) AS INTEGER

Let's take an in depth look at both of the above, why don't we?

First, DIM A AS INTEGER -- this is a declaration that we're adding a single variable to our program, and that it's going to be an INTEGER type.

Then, DIM A(0) AS INTEGER -- this is a declaration that we're going to add an array called A, with an allowable range from 0 to 0, in our program, and it's going to be an INTEGER type.

Now, as far as useful needs inside a program goes, there's honestly not going to be that much difference.  Any place where you could use A, you could use A(0), and vice-versa.  After all, at the end of the day, both are nothing more than single reference points to an integer value in memory.

BUT, there's a big difference in the overhead that comes from those two statements:

For A, as an integer, looking up and using it's value is as simple as just finding the offset, getting the value, and then working with that portion of memory.   If we say "A is an integer at byte 1234 in memory", that's all the machine needs to know to work with the value of A inside our program.  

Now, for A(0), being an array, things get a little more complicated.  First, we have to tell the pc where that array is located in memory.  Then it has to know the type of element that's in that array.  Then it's got to move forward element_size * index, to find the proper portion of memory to work with.  It's a case of saying, "A is an array at byte 1234 in memory, and it's all integers of 2-bytes each, and we want the 0th element of it, so the data we need is at position 1234 + 2 * 0, so we want to look at byte 1234 and get 2 bytes of information."

As you can hopefully see from the wordiness of that statement, there's a lot more to look up and deal with before we interact with A(0), than there is in just dealing with A.

Arrays inherently carry more overhead to them, than just a simple variable does.  They use more processing power, execute slower, and even use more memory overall (as they tend to have larger descriptors associated with them to account for their element range and size and whatnot).  As bplus pointed out, there's even more typing associated with using A(0) over just A.

Honestly, I can't think of any good reason why someone would make use of A(0), instead of just A.  Unless that array is one which you're going to REDIM later and build upon, I honestly don't see how A(0) would ever be more efficient or easier than just using A (or even a simple A0) in your code.

[Dimster]

Thanks very much for this feed back... So they are two different variables (actually a variable and an array) which appear to have the same name    ie -- Event10 = 3124, Event10(0) = 598. I could use one as a temporary hold of a past value for comparison with the present value of Event10. 

But I gather, something like Event10Present = 3124, Event10Past = 598 is more the accepted practice because to the overhead associated with arrays?

[SMcNeill]

Honestly, it's about about what feels natural to you.   The extra overhead is minute, and unless you're just pushing to try and maintain FPS or such, it won't matter.  Memory on a modern machine isn't about trying to always squeek by with as little used as possible.  2 bytes used versus 222 bytes...  In most cases, with machines with 64,000,000,000 bytes of memory, it means squat..

If you check my old cold, you'll see where I do things like so a lot:  OldX = X:  X = _MouseX.   <-- Now I've got present and past values, like you mention.

BUT, with that said, I also remember coding several projects with DIM P(-1 to 0) used.  P(0) was the "original", P(-1) was the "preserved value, and I coded heavily around that concept.   I had constants for CONST Original = 0, Preserved = -1.   Subs were in use like:

SUB ToggleValue (From)
   SHARED P() AS LONG
   P(From) = P(NOT From)
END SUB

The I could do things like IF P(Current) = Foo THEN ToggleValue P(Current)....  And it's all complicated as heck now, but it made sense at the time when I was working with those values (which were associated with pixels and calculating new values from old valuse and such)...

Which just ends with the simple answer:   **Do what feels natural and works best for you.** At the end of the day, it's YOUR code and you're the one who's going to have to write it, edit it, maintain it.  If A = present and A(0) = old makes sense to you, then use it that way.  IF A and OldA make more sense, then use it like that.  IF A(0 TO 1) with a(0) = present and A(1) = old makes sense to you, then use it like that.

End result is:  They all work, and that's the only thing that really matters after all is said and done.  The ONLY reason we program ANYTHING is just for the final product where it compiles and runs and does (mostly) what we want it to.  Don't waste days worrying over, "Is this syntax better than that syntax."  Write the app, compile it, use it, and forget about it.  Leave those theory questions for a classroom exercise.  As long as your code ends up compiling and does what you need it to, isn't that all that REALLY matters when you settle down for a nice steak and beer, before going to bed late at night? 

[Dimster]

Steve - thanks - I often think I've made a short cut only to have it bit me later.

[NakedApe]

So if I understand you right, Steve, you're saying...

IF codeRuns THEN
    IF codeMakesYouHappy THEN
        runCode
        ShowToFriends
        eatSteak&Beer
    ELSE cry-In-Soup
    END IF
END IF