64bit Integer Support?
BlitzMax Forums/BlitzMax Programming/64bit Integer Support?
| ||
| Does BlitzMax have support for 64bit (Unsigned) Integers? |
| ||
| No, it just supports signed 64 bit integers. |
| ||
| 64 bit integers? aren't they 32bit? |
| ||
| AngelDaniel: :Byte - 8 bit unsigned integer :Short - 16 bit unsigned integer :Int - 32 bit integer :Float - 32 bit float :Long - 64 bit integer :Double - 64 bit float |
| ||
| oh, loooooongs :-) |
| ||
| Um... LONG should be 32 bit. BYTE = 8 bits WORD = 2 Bytes LONG = 4 Bytes In most languages Integer is max size for the platform it's compiled on. If anything it should be called Int64 or DLONG. |
| ||
| ArcadeNut: In most languages, but who said BlitzMax had to be like most languages? It's a given that in C and most other languages that long and int are synonymous, and that 'long int' or 'long long' would be 64-bit, but I think this naming convention makes more sense. |
| ||
| The only reason they are synonymous is by coincidence. Todays platforms are mainly 32 bit. In C/C++, Integer on a 64bit platform is 64bits, so it will not by synonymous at that point. If you work on a 16 bit system in C, Integer would be 16bits. As for WHY should BlitzMax be like most languages? Because most of these languages are fairly mature and BlitzMax will probably be used by people who program in multiple languages. If you make it different than other languages "Just because", then you are going to frustrate those who have to switch between languages because this is not a syntactical difference. Data Sizes have been defined for a very long time. Why make it non standard? If you standardize your data sizes it will also make it easier to interface with other languages. |
| ||
| So, uh, why not just code in those languages eh? Personally, this variable naming scheme is tons better.. If variable sizes changed depending on the platform you'd get odd stuff anyway, since you wouldn't really be able to know how big your variables were. Sure, you might have some function or something to do this, but who'e really going to call it just to ensure that their variables are in range? This way you know what size they'll be -no suprise, and their aren't too many variations to remember. |
| ||
| So, uh, why not just code in those languages eh? Because many people use different languages for different purposes. The trick is to find the language that has most pros and fewest cons with regards to the requirements of a given project, and then use that. Sometimes it will be nessecary to use more than one language, and bind them together with XML, JNI or something similar. If variable sizes changed depending on the platform you'd get odd stuff anyway, since you wouldn't really be able to know how big your variables were. In C it's for 2 reasons. One being speed, the other being legacy reasons. Most often you don't really need to know the maximum number your variable can hold, and if you did, you could always stick to using the names that didn't vary depeding on target CPU architecture. |
| ||
| c++ 'int' on 32-bit-system: 32 bit wide c++ 'int' on 64-bit-system: 32 bit wide c++ 'long' on 32-bit-system: 32 bit wide c++ 'long' on 64-bit-system: 64 bit wide c++ 'long long' on 32-bit-system: 64 bit wide c++ 'long long' on 64-bit-system: 64 bit wide what i miss in blitzmax: 1) all signed/unsigned var types 2) 'system-wide' var type (32 bit on 32-bit-machine, 64 bit on 64 bit machine). This is usefull to store memory adresses in this variables. But on other side - i think bbmax produce ony 32-bit-executables - or? |
   |