02-05-2024, 05:50 AM
https://qb64phoenix.com/qb64wiki/index.php/BIT
Why would you even want a _BIT in an User Defined Type?
TYPE foo
A As _Bit
B As _Byte
END TYPE
That bit is going to take a whole byte to be stored, as a byte is the smallest piece of memory in a computer. Write out how you'd expect 3 entries of that to be written to a file. Are you suggesting that that type is now regarded as 9-bits? The first record is from bit 1 to 9, second record from bit 10 to 18, third record from bit 19 to 27, with blank space at bits 28 to 32? 3 data entries using 4-bytes of information?
Man, the overhead on that is going to be INSANE!! Bit packing across data fields! You'll have to calculate start-bit position, turn it into a corresponding byte. (For record two, the starting bit is 10, so that's in byte 2.) Then you read 2 bytes. (byte 2 and 3 of the data record) Then you shift it left so that you position the first bit in the A position for you bit type. Then you truncate anything beyond the 8 bits necessary for the B position. Then you return that value....
*Blink* *Blink*
Is it doable? SURE IT IS!! (You'd have to write your own bit compression routines to do it, however, as it's not something the language supports natively.)
Is it going to use oodles of CPU power, take forever and ever to execute, and cause a massive bottleneck in any programming loops? YEP! INDUBIDABLY!!
What's going to happen would be the same that happens with any variable of _BIT type:
1) That _BIT is going to be stored as a _BYTE.
2) That _BYTE is going to be stored as a _BYTE.
3) Each data field is going to be 2-bytes in size. The only difference is once you read the first byte, it'll perform AND 1 to only keep the bit value.
So your UDT is going to use 6-bytes --- no bit packing -- to store that information, and then it's going to work math on the value which you defined as a _BIT so that it *only* returns one bit out of that byte. Your 3 data records are going to be 6-bytes in size....
...and if they're going to be 2-bytes in size each, anyway, WHY WOULD YOU WANT TO SLOW IT DOWN WITH EXTRA, UNNECESSARY MATHS??
It's like saying:
Type foo
Dim A As _Person
Dim B As _Bus
End Type
Now, you want to drive down the road to get from point A to point B. That _Person can't just run out on the interstate and yell, "Booden!! Booden!!" and motor down the highway. He's got to climb up into a Bus himself, before he's allowed to travel on those roads.
People can't booden booden down the interstate. Bits can't travel through memory. Only Buses and Bytes do that.
Quote:_BIT is not supported in User Defined TYPES. Use a _BYTE and assign up to 8 bit values as shown below.
Why would you even want a _BIT in an User Defined Type?
TYPE foo
A As _Bit
B As _Byte
END TYPE
That bit is going to take a whole byte to be stored, as a byte is the smallest piece of memory in a computer. Write out how you'd expect 3 entries of that to be written to a file. Are you suggesting that that type is now regarded as 9-bits? The first record is from bit 1 to 9, second record from bit 10 to 18, third record from bit 19 to 27, with blank space at bits 28 to 32? 3 data entries using 4-bytes of information?
Man, the overhead on that is going to be INSANE!! Bit packing across data fields! You'll have to calculate start-bit position, turn it into a corresponding byte. (For record two, the starting bit is 10, so that's in byte 2.) Then you read 2 bytes. (byte 2 and 3 of the data record) Then you shift it left so that you position the first bit in the A position for you bit type. Then you truncate anything beyond the 8 bits necessary for the B position. Then you return that value....
*Blink* *Blink*
Is it doable? SURE IT IS!! (You'd have to write your own bit compression routines to do it, however, as it's not something the language supports natively.)
Is it going to use oodles of CPU power, take forever and ever to execute, and cause a massive bottleneck in any programming loops? YEP! INDUBIDABLY!!
What's going to happen would be the same that happens with any variable of _BIT type:
1) That _BIT is going to be stored as a _BYTE.
2) That _BYTE is going to be stored as a _BYTE.
3) Each data field is going to be 2-bytes in size. The only difference is once you read the first byte, it'll perform AND 1 to only keep the bit value.
So your UDT is going to use 6-bytes --- no bit packing -- to store that information, and then it's going to work math on the value which you defined as a _BIT so that it *only* returns one bit out of that byte. Your 3 data records are going to be 6-bytes in size....
...and if they're going to be 2-bytes in size each, anyway, WHY WOULD YOU WANT TO SLOW IT DOWN WITH EXTRA, UNNECESSARY MATHS??
It's like saying:
Type foo
Dim A As _Person
Dim B As _Bus
End Type
Now, you want to drive down the road to get from point A to point B. That _Person can't just run out on the interstate and yell, "Booden!! Booden!!" and motor down the highway. He's got to climb up into a Bus himself, before he's allowed to travel on those roads.
People can't booden booden down the interstate. Bits can't travel through memory. Only Buses and Bytes do that.