unexpected overflow

Topic

New Reply

I quote from VBA help: “Byte variables are stored as single, unsigned, 8-bit (1-byte) numbers ranging in value from 0 to 255.” If that is the case, why when I run the following code do I get an overflow at bteA = 255?

Dim bteA as Byte

For bteA = 32 To 255
‘ My Code Here
Next bteA

I can understand getting an overflow at 256, but not at 255. Is this just one of those things?

Yours, puzzled,

Brooke

Reply | Quote

Replies

I suspect it is because the For_Next loop runs by adding 1 to bteA until it is greater than the ‘to’ value – in your case 255.
In other words, it counts to 256.
If you remove the Dim statement and add a watch, you can see bteA leaves the For_Next loop with a value of 256.

Reply | Quote

When bteA reaches 255 and your code is processed, next bteA increments the value to 256, and hence causes an overflow error. The workaround I suppose is to do bteA 31 to 254, and use (bteA+1) in your code.

Andrew

Reply | Quote

I should have posted a solution while I was thinking about it:

Dim bteA As Byte
For bteA = 250 To 255
' My Code Here
If bteA = 255 Then Exit For
Next bteA

Reply | Quote

Actually, this is a situation where a Do loop is probably preferable, in spite of the fact that it doesn’t autoincrement. For loops are really intended to work with counters and Do loops with conditions. In this case, you could use:

 Do While bteA >=32 and bteA <=255
   <>
   bteA = bteA + 1
 Loop

Reply | Quote

Thank you one and all.

I solved it temporarily by changing to an integer but now I can revert back to a byte.
Charlotte: your code also overflows but that is solved by switching the two lines within the loop and dropping the two conditions by 1. Question: I would normally go for a Do/Loop_Until rather than a Do_While/Loop. Is there any reason for that or is it personal preference?

Thanks again,

Brooke

Reply | Quote

Do Loop Until will always execute at least once, regardless of whether the condition you’re testing for is true, which determines when you use a Do While vs a Loop Until. If the initial condition is already false, a Do While will never execute.

Reply | Quote

I understand. Thanks again.

Brooke

Reply | Quote

Do you have a reason for defining bteA as a byte. From what you have shown, the only advantage I can see is that you would save one byte of storage (unlikely since the storage is on the stack and that is allocated in even words, not bytes). Your “solution” adds about six bytes and two or three instructions that have to execute every time through the loop. The better solution would be to DIM bteA as an integer.

Reply | Quote

I assumed you were asking Leif this question, but maybe not. The reason I used byte in the first place is because I’m under the impression that the smaller the memory overhead, the quicker the routine is likely to be – hence I use the smallest memory types available. I had absolutely no idea that the storage was on the stack or that the stack is allocated in even words, thus negating the effect of using the smaller types.

Question 1 : does anyone have a pointer to some nice data source that will tell me exactly what’s going on in the background so I know how things are stored/allocated/used/etc by the actual computer?

Question 2 : a little way back, wasn’t there some discussion as to whether integer was worth using? I’ve tried searching for the threads but can’t get anywhere – the gist of it was (as i remember it) that integer was just a special case of double, and vba took longer to recognise this than the time saved by making it smaller than double – if this is the case, where does this recidivism end? Or should I just time everything and see what works faster in a given situation?

Brooke

Reply | Quote

Brooke,

I suspect the time difference between byte, Integer and long is miniscule.

I’d go for the longest data type which could ever exist.

I’ve seen an application crash disastrously after months in production trouble-free because a record counter in the database exceeded 32767- it was defined in the VB application as Integer.

That sort of thing is far more costly than the very few machine cycles of a byte vs integer vs long.

Reply | Quote

There is, unfortunately, no one answer. First, all intel processors access memory a word at a time. So, it makes little or no difference in speed to use a byte versus a word. In fact, it can could actually slow things down if the program has to add an extra instruction to clear the other half of the word when the values is loaded into a register. The only real reason for using byte vs integer is if it would save storage, and then usually only if the saving were repeated many times in file records or memory tables. On 32 bit processors, it is usually faster to use a long integer as that is the size that the processor is going to work with anyhow.

Exactly what affect using different size variables will have on speed is going to be different depending on what processor the program is run on, and what programming language and version is used. With the speed of today’s processors, it is usually only worth trying to figure it out if you are running a very time dependant real time program.

Reply | Quote