Results 1 to 12 of 12
  1. #1
    5 Star Lounger
    Join Date
    Dec 2000
    Location
    Reading/Swindon, Berkshire, United Kingdom
    Posts
    664
    Thanks
    0
    Thanked 0 Times in 0 Posts

    unexpected overflow

    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

  2. #2
    Plutonium Lounger Leif's Avatar
    Join Date
    Dec 2000
    Location
    U.K.
    Posts
    14,010
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: unexpected overflow

    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.

  3. #3
    Gold Lounger
    Join Date
    Feb 2001
    Location
    Dublin, Ireland, Republic of
    Posts
    2,697
    Thanks
    1
    Thanked 0 Times in 0 Posts

    Re: unexpected overflow

    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

  4. #4
    Plutonium Lounger Leif's Avatar
    Join Date
    Dec 2000
    Location
    U.K.
    Posts
    14,010
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: unexpected overflow

    I should have posted a solution while I was thinking about it:
    <pre>Dim bteA As Byte
    For bteA = 250 To 255
    ' My Code Here
    If bteA = 255 Then Exit For
    Next bteA
    </pre>


  5. #5
    Plutonium Lounger
    Join Date
    Dec 2000
    Location
    Sacramento, California, USA
    Posts
    16,775
    Thanks
    0
    Thanked 1 Time in 1 Post

    Re: unexpected overflow

    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:

    <pre> Do While bteA >=32 and bteA <=255
    <<your code>>
    bteA = bteA + 1
    Loop</pre>

    Charlotte

  6. #6
    5 Star Lounger
    Join Date
    Dec 2000
    Location
    Reading/Swindon, Berkshire, United Kingdom
    Posts
    664
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: unexpected overflow

    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

  7. #7
    Plutonium Lounger
    Join Date
    Dec 2000
    Location
    Sacramento, California, USA
    Posts
    16,775
    Thanks
    0
    Thanked 1 Time in 1 Post

    Re: unexpected overflow

    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.
    Charlotte

  8. #8
    5 Star Lounger
    Join Date
    Dec 2000
    Location
    Reading/Swindon, Berkshire, United Kingdom
    Posts
    664
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: unexpected overflow

    I understand. Thanks again.

    Brooke

  9. #9
    Uranium Lounger
    Join Date
    Jan 2001
    Location
    South Carolina, USA
    Posts
    7,295
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: unexpected overflow

    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.
    Legare Coleman

  10. #10
    5 Star Lounger
    Join Date
    Dec 2000
    Location
    Reading/Swindon, Berkshire, United Kingdom
    Posts
    664
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: unexpected overflow

    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

  11. #11
    Platinum Lounger
    Join Date
    Dec 2000
    Location
    Queanbeyan, New South Wales, Australia
    Posts
    3,730
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: unexpected overflow

    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.
    Subway Belconnen- home of the Signboard to make you smile. Get (almost) daily updates- follow SubwayBelconnen on Twitter.

  12. #12
    Uranium Lounger
    Join Date
    Jan 2001
    Location
    South Carolina, USA
    Posts
    7,295
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: unexpected overflow

    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.
    Legare Coleman

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •