Your approach doesn't work because the variable length int (and long)
approaches used write data in chunks of bytes, where data is only
allowed in the 7 LSBs of the byte. The MSB of each byte (which would
otherwise contain the sign of the number in usual signed, 2's
complement) now contains a marker indicating whether there is another
byte to come.
On 3 Sep 2009, at 12:48, Galder Zamarreno wrote:
On 09/03/2009 01:29 PM, Galder Zamarreno wrote:
> On 09/03/2009 12:53 PM, Galder Zamarreno wrote:
>> Hi,
>>
>> While looking at
https://jira.jboss.org/jira/browse/ISPN-149, I've
>> realised that writeUnsignedInt(), due to its dynamic behaivour, it's
>> more efficient than using a leading byte and then writing a byte,
>> short
>> or int.
>>
>> However, I've spotted an unefficiency in
>> UnsignedNumeric.writeUnsignedInt() which is that if you write a byte
>> that's between 128-255, it writes two bytes, whereas in theory, you
>> could just write it as a single unsigned byte.
>>
>> Now, I'm not an expert on these methods, but I believe a
>> writeUnsignedInt like this would make 128-255 bytes be written as
>> 1 byte
>> too:
>>
>> public static void writeUnsignedInt(ObjectOutput out, int i)
>> throws
>> IOException {
>> while ((i& ~0xFF) != 0) {
>> out.writeByte((byte) ((i& 0xFF) | 0x100));
>> i>>>= 8;
>> }
>> out.writeByte((byte) i);
>> }
>>
>> And the read part would look like:
>>
>> public static int readUnsignedInt(ObjectInput in) throws
>> IOException {
>> int b = in.readUnsignedByte();
>> int i = b& 0xFF;
>> for (int shift = 8; (b& 0x100) != 0; shift += 8) {
>> b = in.readUnsignedByte();
>> i |= (b& 0xFFL)<< shift;
>> }
>> return i;
>> }
>
> Hmmm, the read part is not working as expected. Trying to figure
> out how
> to get on values equal or bigger than 256 to read the next byte.
Hmmm, this is trickier than I thought. In the current solution, you
know
you have to read more bytes cos the byte you've just read is negative.
However, if you use the full 4 bytes, how do you know that you need to
read another byte? Hmmmm....
>
>> Manik, I think you created these methods in the 1st place, thoughts?
>> CC'ing David M L who's quite an expert on this too.
>>
>> Cheers,
>
--
Galder ZamarreƱo
Sr. Software Engineer
Infinispan, JBoss Cache
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev