Booleans?
BlitzMax Forums/BlitzMax Beginners Area/Booleans?
| ||
| So...are there no booleans in Blitz? |
| ||
| There are no booleans on any 32Bit OS actually. The lowest normally is Int the rest is just slowed down by bitshifting and masking for Byte and Short. BM has true and false if you meant that. They are represented as Int |
| ||
| Although it would be "nice" to have a boolean type as in C, at the end of the day a boolean is just a fancy word for an integer that is either 0 or 1 (or some other non-0 value) Local boolean:Int boolean = true boolean = false if boolean then ,,, |
| ||
| so the byte type is less efficient then an int? |
| ||
| In terms of speed, yes, most of the time. Naturally it is MORE efficient in terms of space. |
| ||
| How would it be more efficient? OS only stores 32Bit blocks in the RAM not 8Bit blocks ... so in the end you will lose 3Byte if you insist on using Byte. Best example here are crappily designed types. Byte Int Byte in a type can take 12 Byte if this is the only thing in there while Byte Byte Int will use 8 Byte |
| ||
| Are you sure? Why is Long not limited to 32-bits? |
| ||
| Because it takes 2 int blocks But anything below an int will end up as an int. You can not adress sub-int precision on a 32bit OS directly, simply due to the fact that the OS itself only addresses on INT level ie 32bit / 4 Byte Everything below that is achieved through bitshift and the OS memory manager addresses each chunk as a single 4 byte block. The sub usage is up to the app. So an excellent compiler would actually shift the definitions before creating the executable code to make sure it is using as less RAM as possible but with the current amount of RAM it is not needed to enforce that, it will only raise the compilation time if you do not use "quick compile" attempts |
| ||
| How would it be more efficient?... I don't think you read carefully. I said it's more efficient in terms of SPACE, that's pretty much by definition. In terms of speed, it is naturally less efficient.Also, you seem to be mistaken here. Two things: 1) It is true that "generally" (read : "almost always, for speed sake") the compiler will store individual bytes in 32 bits slots anyway. It has nothing to do with the OS, but with the CPU for alignment issues, and with the fact that compiler writers do know this and accordingly align data. Also, note that intel processors CAN adress individual bytes (by contrast, most RISC processors can't), it's just slower. Even if it couldn't, that would just require the compiler to add some masking to access the individual byte (and naturally be even slower). And I don't say "generally" fortuitely. A compiler is free to store a byte field in only 8 bits. Actually in most C++ compilers you have directives to tell the compiler not to do any alignment and remove any padding in structs/classes. 2) In byte arrays, almost any compiler will store individual byte elements condiguously, as in this case it would certainly waste too much space (not to say it is mandated in certain languages that elements must be contiguous) |
   |