Re: [boost] [B-tree] Continuing development

Subject: Re: [boost] [B-tree] Continuing development
From: Brian Wood (woodbrian77_at_[hidden])
Date: 2010-09-27 19:00:00

OvermindDL1:
<woodbrian77_at_[hidden]> wrote:
>>
>> Just fyi, I've been experimenting with a similar string --
>> http://webEbenezer.net/misc/lil_string.hh .
>>
>> If an operation would result in a string with length more than 255,
>> an exception is thrown. ?This allows the length of the string to be
>> marshalled with one byte. ?As you mention this limitation is not a
>> problem in many circumstances. ?I'd quibble a little with it not being
>> suitable for demanding applications. ?I think it is fine to use it in that
>> context, but that you might need to also use other string classes.
>
> Why not use a compressed uint type?  Google's Protocol Buffers
> compressed uint compresses an uint just fine, below 128 will be
>represented in one byte, etc..., it works very simply, by just having
> the MSB be a marker indicating the last byte of the integer if it is
> zero, thus it is base 128 instead of base 256 per byte, so as an
> example:
> hex  ->  compressed bits
> 0    ->  0000 0000
> 1    ->  0000 0001
> 300  ->  1010 1100 0000 0010
> And so forth, and if you have looked in the protocol buffer source it
> decodes each byte very quickly and efficiently.  So if you are worried
> about space, you could use this (especially since I have many use
> cases where strings would exceed 255 characters, and we need a
> 'bytestream' type or so too).

I've thought about doing that and I'm using that technique in one
place in my library.  The only thing I can say is I like the documentation
effect that the name lil_string has.  I don't claim what you suggest is a
bad idea, but at the moment I'm happy with what I have.

-- 
Brian Wood
Ebenezer Enterprises
http://webEbenezer.net
[phone]