Additional Datatypes planned?
BlitzMax Forums/BlitzMax Programming/Additional Datatypes planned?
| ||
| Hey ppl, Are there any plans to add additional datatypes like Unsigned versions of the existing numeric types? |
| ||
| Also being able to SAVE images would be useful ;-) |
| ||
| Bit off topic there. Unsigned types might be useful for dealing with memory in particular. |
| ||
| Angel, there is a saveimage routine in the bpaint sample. |
| ||
| skid: I think the point of the question (well, pseudo-question as there is no question mark) was whether or not there will be an official SaveImage procedure. It would make it a lot easier for some people I think. You could've included some insight into whether or not there would be new data types as well... |
| ||
| You could've included some insight into whether or not there would be new data types as well... ...except that he doesn't know. I do, however. There are no additional datatypes planned. |
| ||
| :( |
| ||
| I do, however. There are no additional datatypes planned. Why not? |
| ||
| More to the point, why? Adding signed/unsigned would add 4 new types to the language and introduce a bunch of new and not terribly obvious rules governing type conversions. See the bits on signed/unsigned at http://publications.gbdirect.co.uk/c_book/chapter2/expressions_and_arithmetic.html to get some idea of how much complexity unsigned can add. Note the quote: The moral is to steer clear of unsigned numbers unless you really have to use them, and to be perpetually on guard when they are mixed with signed numbers. Unsigned tends to have a 'viral' effect on code, too. Once you start using unsigned, there is a tendancy for it to 'infect' other bits of your code forcing you to declare other variables unsigned. This would be esp. true in Max which doesn't do 'warnings'. I haven't used unsigned in my own C++ code for a long time. Several C++ books I've read on the subject reckon its best to avoid using unsigned. Java gets along quite nicely without it. And on the 'pro' side...? One extra bit for positive only values, and not having to go 'And >=0' every now and then. |
| ||
| fare enough, but what happends when you for example want to access a file larger than the signed long? it could happend, and infact has happend many times while trying to access verious things. |
| ||
| Fair enough, but I think you'll be encountering a lot of backlash from this decision, Mark. By the way, you seem to be a bit edgy lately- if I were you I'd just take a couple weeks off to relax. It's nearing Christmas, after all, so I don't see why not. |
| ||
| I gave him a headache... But I promised to be good from now on. :) |
| ||
| Just me being silly maybe, but isnt the sign of a int stored in just one bit. Unsigned and signed ints take the same room (32bits) in memory. The only real place you want to be using it too is when your talking to other language libs. The point im trying to get too is, you can still pass that unsigned int, but blitz will look at it as an signed int. Just dont use blitz to do the maths onit. want to access a file larger than the signed long Your using a games laguage, that would have to be some big arsed file. And why would't you want to split that into a number of smaller files?. <nevermind, retroical question!> |
| ||
| Unsigned and signed ints take the same room (32bits) in memory. Yes, the effect is that you can have a positive number that is twice as large as it could be in the same number of bits otherwise. A byte can be from -128 to 127, or 0 to 255. want to access a file larger than the signed long So use a signed double. If you need more than one terrabyte or whatever it's called of anything, then you have MUCH more important things to worry about =] Like whether you really should be designing a program for NASA on a home PC or not ;] |
| ||
| Shagwana: small word "Movies" for one. uhmm a signed long = -2147483648 to +2147483647, since files start at 0, we only have 2147483647 bytes at which we can look at that's 2.1gb. And just for reference, BlitzMax isn't a game programming language neither is it an application language it is, both and the same thing. |
| ||
actually from my calculations a long in blitzmax has the value -9223372036854775808 to 9223372036854775807strict Local a:Long=9223372036854775807:Long Print a Print LongHex(a) |
| ||
| Oh no! We're limited to 2 gigabyte files! You know, even the DVD people were smart enough to break up vob files into 2gig chunks. Or were they... <checks> No, sorry, I'm talking thru my bot-bot. They split them into 1gig files. That's ... a strange number. But it's a good principle to follow. I could only imagine there being a problem for reading things like DVD-ISO files... But then, as I said, use a double. An extra 32bits for one (or ten) variable ain't gunna kill ya. BlitzMax isn't a game programming language neither is it an application language it is, both and the same thing. I agree, but they're marketing (yes, well, if you can call it that:) it as a game language, so keep that in mind. |
| ||
| Doesn't BlitzMax use 32 bit ints for file access currently? Changing that to (Max) longs might be a good idea. |
| ||
| Riot, in blitzmax a long is a 64 bit integer while your double is a 64 bit floating point. |
| ||
| ahh, finally the little light shows at last :) |
| ||
| Riot, in blitzmax a long is a 64 bit integer while your double is a 64 bit floating point. Right, thanks for clearing that up for me. Now Michael's post makes more sense =] |
| ||
| actually from my calculations a long in blitzmax has the value -9223372036854775808 to 9223372036854775807 And considering the maximum filesize on NTFS is only 16 terrabyte... |
| ||
| It is actually 15 Terrabytes, 999 Gigabytes, 999 Megabytes and 934 kilobytes ;) |
| ||
| So use a signed double. If you need more than one terrabyte or whatever it's called of anything, then you have MUCH more important things to worry about =] Like whether you really should be designing a program for NASA on a home PC or not ;] Remind me to quote you on that in 10 years time just to embarrass you ;-) |
| ||
| I think it's prolifically relevant =] |
   |