Type Sized For Loops
BlitzMax Forums/BlitzMax Programming/Type Sized For Loops
| ||
| Not much of a topic title, I know, but it's a little too weird to describe. ( Don't run this unless you've saved your work as it will crash the IDE ) For Local B:Byte=0 to 255 Print B Next or For Local S:Short=0 to 65535 Print S Next Yeah, so it just keeps going.. round and round.. Tested it in PureBasic and IBasic, and neither of those seems to have any problem doing it. Tested in B3D ( with an Int, obviously ) and it takes bloody ages to get up that high, but I left it a pretty long time, so it looks as though B3D had this problem too. I can only assume that Blitz is checking to see if the number is higher the next time you go around when it should actually be checking if the number is equal before going around again. Or something like that. I've just wasted an hour hunting down a mysterious bug which was hanging my program, and this appears to be it. :( |
| ||
| hah, so it wraps and continues to loop, that's quite funny, esp. as I wasn't the one bug hunting for an hour. |
| ||
| Unfortunately, this is due to the limits imposed by shorts and bytes. My advice? Use an int. There's no benefit to using it over a short or byte since for most operations they'll be converted to an int and then converted back to a byte when the operations are finished. In this case it's like: For i@ = 0 To 255 -Convert to int -Increment -Convert to byte -Compare Next |
| ||
| I just used Shorts and Bytes as an example. The same thing happens with Ints, if you should happen to want a loop that large. Both PB and IB have the same datatypes and they don't foul up like this. |
| ||
| When the type reaches the upper limit of what numbers it can represent, the for-next loop adds 1 to it for the next iteration before testing to see whether to do another iteration, and since adding 1 to the upper limit makes 0, it is fooled to thinking there is more to do so it keeps going. It's not so much a bug it's just they haven't deliberately placed a protective mechanism in there to detect when this is happening. You can change your loop type to something else, like a while-wend or repeat-until loop, and manage the counter yourself using bytes or whatever you want - you can then error-check for the upper limit being reached. |
| ||
| When the type reaches the upper limit of what numbers it can represent, the for-next loop adds 1 to it for the next iteration before testing to see whether to do another iteration, and since adding 1 to the upper limit makes 0, it is fooled to thinking there is more to do so it keeps going. It's not so much a bug it's just they haven't deliberately placed a protective mechanism in there to detect when this is happening. I said exactly that just above. You can change your loop type to something else, like a while-wend or repeat-until loop, and manage the counter yourself using bytes or whatever you want - you can then error-check for the upper limit being reached. I hardly need help working around it. The point is, you can only work around if you know there's a problem, and how likely are you to think that Blitz messes this up when other languages don't? We can argue semantics over the difference between a bug and "the lack of a deliberately placed protective mechanism" till the cows come home, but there's no good reason for it to behave as it does, and it's going to continue causing problems if it's not taken care of. |
| ||
| sound like a pretty serious bug |
| ||
| That behavior is known and nothing new. Ever read the bug board before posting stuff? |
| ||
| That behavior is known and nothing new. Judging by the reactions to this thread, it seems to be new to quite a few people. Ever read the bug board before posting stuff? Since I hadn't confirmed it was happening across the board and not just one of those weird little thing that happens until you reboot and goes away, and since I wasn't posting in the bug forum, no. |
   |