How is the getBitRange method supposed to work in MemoryBlock?
I added a single byte with value ‘1’ to the memory block, then called “getBitRange (0, 6)” on it, to retrieve the value present in the 6 most significant bits… I thought I would have got a value of 0 for that, while it returned 1 as if it were taking the least significant bits
i’ve been struggling with this for two days i think, so i wrote myself a map for the first 12bytes since i need the bits for them later on, here is what i came up with
Yes, bits are usually numbered from right to left,while single bytes are usually visualized from left to right,that’s the origin of confusion in my case.
If it’s of any help to you, think in these terms: the current implementation of getBitRange returns bits numbered as if the whole binary content of the block was a little endian integer stored in memory, with least significant bytes in the lowest locations (here represented by the first elements of the block).
This is of little help in case you are doing stream operations on the single bits though. In that case, I’d like bit 0 to be the “leftmost” of the first byte (byte 0), bit 7 would be the rightmost of the same byte, bit 8 the leftmost of byte 1, bit 15 the rightmost of byte 1 and so on… what do you think about adding a second getBitRange-like method that follows this order?
…but that’s just not how bits are numbered! Bit 0 of a byte is always (1 << 0), bit 2 is (1 << 2), bit 3 is (1 << 3), etc. Nobody talks about bit 1 as being (0x80 >> 1) !
The way it’s currently done is little-endian, and the only other non-silly way it could be arranged would be big-endian, but that wouldn’t involve changing the bit-order, it’d just mean that the bits would be numbered starting from the last byte in the block, and increasing towards the start of the block. That’s a valid approach too, but would be confusing because when you change the size of the block, it’d change the numbering of all the existing bits.
My intention was to use the MemoryBlock as a sort of bit array with bits numbered left to right like the elements in a vector or array
edit: and if the “quite simply wrong” thing was for me, I’d like you to try implementing the base64 encoding of a MemoryBlock with that getBitRange, then let me know if my request still look absurd to you.
I’m not saying that it’s not in any way useful to be able to view data like that, but it’s not really the way memory is treated, and doesn’t really fit the remit of this particular class. It’s the sort of job you’d have an auxiliary class to handle.
That’s where I started from for my own implementation of the standard base64, and that’s where getBitRange is being used in the first place. I thought the custom base 64 encoding in JUCE was using a similar approach to the standard one, but that’s where I discovered this bit ordering difference between the two methods