TBank, autosize or what?
BlitzMax Forums/BlitzMax Programming/TBank, autosize or what?
| ||
| I noticed that the following code prints all 8 numbers. However, the banksize is only 5 bytes. So why does it allow the storage of 3 extra bytes? Does it autoresize? (if so, THATS GREAT!!... but whats the disadvantage? is it slower?.... currently im manualy resizing banks because i assumed all the time it was not possible to write outside of the range...) All comments are welcome! I need to learn how this think works. Local b:TBank=CreateBank(5) b.PokeByte(0,Byte(1)) b.PokeByte(1,Byte(2)) b.PokeByte(2,Byte(3)) b.PokeByte(3,Byte(4)) b.PokeByte(4,Byte(5)) b.PokeByte(5,Byte(6)) b.PokeByte(6,Byte(7)) b.PokeByte(7,Byte(8)) Print b.PeekByte(0) Print b.PeekByte(1) Print b.PeekByte(2) Print b.PeekByte(3) Print b.PeekByte(4) Print b.PeekByte(5) Print b.PeekByte(6) Print b.PeekByte(7) |
| ||
| It probobly resizes every time you add beyond the initial size. Every time it resizes it likely needs to cast the previous bank into a new enlarged one. Could get very slow in larger banks, like slicing arrays. Resource vs Speed. |
| ||
| Are you running in Release mode? Because in Debug mode you should be getting an assertion when poking around in places you shouldn't... |
| ||
| I've never heard of banks automatically resizing. Arrays don't do it so why should a bank? If you are not in debug mode you might be able to get away with it, but in debug I think you should be getting an error. |
| ||
There's an echo in here...Method PokeByte( offset,value ) Assert offset>=0 And offset<_size Else "Illegal bank offset" |
| ||
| ah, i have debug modes turned off. I didnt know it would actualy contain such routines. I thoughd "when i get an error in release modes, i turn on the debugger for debugging". But i guess thats not a good idea? |
| ||
| Debug mode compiles additional code for bounds checking and so on so that you can ensure your program is free of bugs as much as possible. This has a drawback ... it slows your code down. So... Release mode doesn't compile any checking code so that your program will run as fast as possible. However, this has the drawback that if any bugs are not found/finxed, that your program could crash. Poking outside of memory that hasn't been reserved is an example of how this could happen. |
| ||
| or going out of array bounds, as the debug extra code isn't part of the release build as well. Seems like you never heard the term "debugging" which naturally assumes "debug" to be the mode in which you do it :) |
| ||
| haha, there is a point in that. i see now how debuggin is ment to prevent and not to solve. thanks. |
| ||
| Debugging is really a part of your development process and shouldn't be something you need when you release your final product. You use it for testing and making sure you are doing everything in the way that the language allows. Then when you've got your bugs out you can go to release mode. |
   |